Mark Simulacrum [Sun, 28 May 2017 02:54:04 +0000 (20:54 -0600)]
Rollup merge of #42260 - stjepang:document-cmp-traits-agreement, r=alexcrichton
Docs: impls of PartialEq/PartialOrd/Ord must agree
Fixes #41270.
This PR brings two improvements to the docs:
1. Docs for `PartialEq`, `PartialOrd`, and `Ord` clarify that their implementations must agree.
2. Fixes a subtle bug in the Dijkstra example for `BinaryHeap`, where the impls are inconsistent.
Thanks @Rufflewind for spotting the bug!
bors [Sat, 27 May 2017 20:35:25 +0000 (20:35 +0000)]
Auto merge of #42137 - nical:doc-clone, r=BurntSushi
Update to Rc and Arc documentation to favor the Rc::clone(&ptr) syntax.
This is a followup of the discussion in https://github.com/rust-lang/rfcs/pull/1954.
The solution chosen by the core team to address the problem tackled by the [the RFC](https://github.com/rust-lang/rfcs/pull/1954) was to make the function call syntax Rc::clone(&foo) the idiomatic way to clone a reference counted pointer (over the method call syntax foo.clone()).
This change updates the documentation of Rc, Arc and their respective Weak pointers to reflect this decision and bring more exposure to the existence of the function call syntax.
bors [Sat, 27 May 2017 11:23:45 +0000 (11:23 +0000)]
Auto merge of #42109 - Keruspe:master, r=alexcrichton
rustbuild: don't create a source tarball when installing
This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command.
This will allow splitting install in a few rules if we want as it's done for other phases.
bors [Sat, 27 May 2017 05:28:24 +0000 (05:28 +0000)]
Auto merge of #42068 - petrochenkov:ustab, r=nikomatsakis
Stabilize unions with `Copy` fields and no destructor
What else is needed:
- [x] Documentation (https://github.com/rust-lang-nursery/reference/pull/57).
- [x] Making assignments to `Copy` union fields safe (https://github.com/rust-lang/rust/pull/42083).
- [ ] Backport? (The "stabilization decision" is from [Apr 13](https://github.com/rust-lang/rust/issues/32836#issuecomment-294018091), it's just this PR is late.)
cc https://github.com/rust-lang/rust/issues/32836
r? @nikomatsakis
bors [Fri, 26 May 2017 18:11:54 +0000 (18:11 +0000)]
Auto merge of #42081 - ishitatsuyuki:submodule-better, r=aidanhs
Use the improved submodule handling
r? @alexcrichton
That was a crap...
```
Updating submodules
Traceback (most recent call last):
File "./x.py", line 20, in <module>
bootstrap.main()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 684, in main
bootstrap()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 662, in bootstrap
rb.update_submodules()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 566, in update_submodules
path = line[1:].split(' ')[1]
TypeError: a bytes-like object is required, not 'str'
```
Maybe we need to confirm the compatibility of git options, such as `git config` or `git -C` (I believe they existed long before, though). This is tested locally.
bors [Fri, 26 May 2017 10:17:51 +0000 (10:17 +0000)]
Auto merge of #42083 - petrochenkov:safeassign, r=nikomatsakis
Make assignments to `Copy` union fields safe
This is an accompanying PR to PR https://github.com/rust-lang/rust/pull/42068 stabilizing FFI unions.
This was first proposed in https://github.com/rust-lang/rust/issues/32836#issuecomment-281296416, see subsequent comments as well.
Assignments to `Copy` union fields do not read any data from the union and are [equivalent](https://github.com/rust-lang/rust/issues/32836#issuecomment-281660298) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular.
It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code.
bors [Fri, 26 May 2017 07:36:25 +0000 (07:36 +0000)]
Auto merge of #42058 - froydnj:thiscall-support, r=nikomatsakis
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and also enables people to begin experimenting with C++ FFI support on that platform.
bors [Thu, 25 May 2017 22:31:34 +0000 (22:31 +0000)]
Auto merge of #40847 - jseyfried:decl_macro, r=nrc
Initial implementation of declarative macros 2.0
Implement declarative macros 2.0 (rust-lang/rfcs#1584) behind `#![feature(decl_macro)]`.
Differences from `macro_rules!` include:
- new syntax: `macro m(..) { .. }` instead of `macro_rules! m { (..) => { .. } }`
- declarative macros are items:
```rust
// crate A:
pub mod foo {
m!(); // use before definition; declaration order is irrelevant
pub macro m() {} // `pub`, `pub(super)`, etc. work
}
fn main() {
foo::m!(); // named like other items
{ use foo::m as n; n!(); } // imported like other items
}
pub use foo::m; // re-exported like other items
// crate B:
extern crate A; // no need for `#[macro_use]`
A::foo::m!(); A::m!();
```
- Racket-like hygiene for items, imports, methods, fields, type parameters, privacy, etc.
- Intuitively, names in a macro definition are resolved in the macro definition's scope, not the scope in which the macro is used.
- This [explaination](http://beautifulracket.com/explainer/hygiene.html) of hygiene for Racket applies here (except for the "Breaking Hygiene" section). I wrote a similar [explanation](https://github.com/jseyfried/rfcs/blob/hygiene/text/0000-hygiene.md) for Rust.
- Generally speaking, if `fn f() { <body> }` resolves, `pub macro m() { <body> } ... m!()` also resolves, even if `m!()` is in a separate crate.
- `::foo::bar` in a `macro` behaves like `$crate::foo::bar` in a `macro_rules!`, except it can access everything visible from the `macro` (thus more permissive).
- See [`src/test/{run-pass, compile-fail}/hygiene`](https://github.com/rust-lang/rust/pull/40847/commits/afe7d89858fd72b983e24727d6f4058293153c19) for examples. Small example:
```rust
mod foo {
fn f() { println!("hello world"); }
pub macro m() { f(); }
}
fn main() { foo::m!(); }
```
Limitations:
- This does not address planned changes to matchers (`expr`,`ty`, etc.), c.f. #26361.
- Lints (including stability and deprecation) and `unsafe` are not hygienic.
- adding hygiene here will be mostly or entirely backwards compatible
- Nested macro definitions (a `macro` inside another `macro`) don't always work correctly when invoked from external crates.
- pending improvements in how we encode macro definitions in crate metadata
- There is no way to "escape" hygiene without using a procedural macro.
bors [Thu, 25 May 2017 19:48:14 +0000 (19:48 +0000)]
Auto merge of #42220 - alexcrichton:update, r=brson
Update OpenSSL download location
In rustbuild itself we download from our mirror but in the containers we don't
do this yet. The OpenSSL download url changes from time to time (it breaks when
they release a new version) so let's download from our mirror instead.
Alex Crichton [Thu, 25 May 2017 17:07:41 +0000 (10:07 -0700)]
Update OpenSSL download location
In rustbuild itself we download from our mirror but in the containers we don't
do this yet. The OpenSSL download url changes from time to time (it breaks when
they release a new version) so let's download from our mirror instead.
bors [Thu, 25 May 2017 14:10:10 +0000 (14:10 +0000)]
Auto merge of #42052 - kennytm:fix-42007-ice-on-decode-lint-id, r=nikomatsakis
Refactor: Move the mutable parts out of LintStore. Fix #42007.
* #42007 happens because the `Session` `LintStore` is emptied when linting.
* The `Session` `LintStore` is emptied because the checker (`Early`/`LateContext`) wants ownership.
* The checker wants ownership because it wants to mutate the pass objects and lint levels.
The ownership of the whole store is not essential, only the lint levels and pass objects need to be owned. Therefore, these parts are extracted out of the `LintStore` into a separate structure `LintSession`. The "check crates" methods can operate on `&mut LintSession` instead of `&mut LintStore`.
This is a minor *breaking change* for lint writers since the `LintContext` trait is changed: the `mut_lints` and `level_stack` methods are removed. But no one outside of `librustc/lint/context.rs` is using these functions, so it should be safe.
Mark Simulacrum [Thu, 25 May 2017 01:50:07 +0000 (19:50 -0600)]
Rollup merge of #42177 - est31:master, r=Mark-Simulacrum
Remove some needless // gate-test- comments
Also, add detection to treat such comments as tidy errors.
We also remove the found_lib_feature code because it
was just repeating the found_feature code. Originally it
was intended to allow for gate-test lines for
lib features, but apparently nobody missed it.
Mark Simulacrum [Thu, 25 May 2017 01:50:04 +0000 (19:50 -0600)]
Rollup merge of #42149 - dvyukov:license, r=brson
libstd/sync/mpsc: relicense under rust license
These files are licensed under a different license
than the rest of the codebase. This causes potential
issues and inconveniences.
Relicense these files under the standard license.
I hold original copyright on that code.
Mark Simulacrum [Thu, 25 May 2017 01:50:01 +0000 (19:50 -0600)]
Rollup merge of #42134 - scottmcm:rangeinclusive-struct, r=aturon
Make RangeInclusive just a two-field struct
Not being an enum improves ergonomics and consistency, especially since NonEmpty variant wasn't prevented from being empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait.
This is definitely a breaking change to anything consuming `RangeInclusive` directly (not as an Iterator) or constructing it without using the sugar. Is there some change that would make sense before this so compilation failures could be compatibly fixed ahead of time?
Mark Simulacrum [Thu, 25 May 2017 01:50:00 +0000 (19:50 -0600)]
Rollup merge of #42071 - nrc:parse-mods, r=nikomatsakis
Add an option to the parser to avoid parsing out of line modules
This is useful if parsing from stdin or a String and don't want to try and read in a module from another file. Instead we just leave a stub in the AST.
Nathan Froyd [Wed, 17 May 2017 13:40:46 +0000 (09:40 -0400)]
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
est31 [Tue, 23 May 2017 18:17:38 +0000 (20:17 +0200)]
Remove some needless // gate-test- comments
Also, add detection to treat such comments as tidy errors.
We also remove the found_lib_feature code because it
was just repeating the found_feature code. Originally it
was intended to allow for gate-test lines for
lib features, but apparently nobody missed it.