Alex Crichton [Fri, 10 Mar 2017 22:51:32 +0000 (16:51 -0600)]
Rollup merge of #40336 - alexcrichton:fast-dep-info, r=nrc
rustc: Exit quickly on only `--emit dep-info`
This commit alters the compiler to exit quickly if the only output being emitted
is `dep-info`, which doesn't need a lot of other information to generate.
Alex Crichton [Fri, 10 Mar 2017 22:51:27 +0000 (16:51 -0600)]
Rollup merge of #40297 - alexcrichton:fix-submodules, r=brson
Don't put Cargo into the rustc workspace
This causes problems when first cloning and bootstrapping the repository
unfortunately, so let's ensure that Cargo sticks around in its own workspace.
Because Cargo is a submodule it's not available by default on the inital clone
of the rust-lang/rust repository. Normally it's the responsibility of the
rustbuild to take care of this, but unfortunately to build rustbuild itself we
need to resolve the workspace conflicts.
To deal with this we'll just have to ensure that all submodules are in their own
workspace, which sort of makes sense anyway as updates to dependencies as
bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any
case this commit removes Cargo from the global workspace which should resolve
the issues that we've been seeing.
To actually perform this the `cargo` submodule has been moved to a new `vendor`
directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace.
Alex Crichton [Fri, 10 Mar 2017 22:51:20 +0000 (16:51 -0600)]
Rollup merge of #40239 - nagisa:death-to-plugins, r=nikomatsakis
Remove ability for plugins to register a MIR pass
In recent months there have been a few different people investigating how to make a plugin that
registers a MIR-pass – one that isn’t intended to be eventually merged into rustc proper.
The interface to register MIR passes was added primarily for miri (& later was
found to make prototyping of rustc-proper MIR passes a tiny bit faster). Since miri does not use
this interface anymore it seems like a good time to remove this "feature".
For prototyping purposes a similar interface can be added by developers themselves in their custom
rustc build.
```
error: cannot index a value of type `({integer},)`
--> <anon>:3:21
|
3 | println!("☃{}", tup[0]);
| ^^^^^^
|
help: to access tuple elements, use tuple indexing syntax as shown
| println!("☃{}"tup.00]);
error: aborting due to previous error
```
`CodeSuggestion::splice_lines` is misusing `Loc.col` (`CharPos`) as a byte offset when slicing source.
Alex Crichton [Fri, 10 Mar 2017 22:51:14 +0000 (16:51 -0600)]
Rollup merge of #39918 - petrhosek:fuchsia-ci, r=alexcrichton
travis: Fuchsia builder
This change introduces a Dockerfile and script which builds a complete
Fuchsia toolchain which can be used to build Rust distribution for
Fuchsia. We only support cross-compiling at the moment, hence only
setting the target.
Alex Crichton [Fri, 10 Mar 2017 22:51:13 +0000 (16:51 -0600)]
Rollup merge of #39820 - jonasbb:export-attributes, r=nrc
Export attributes in save-analysis data
Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation.
I would like to change the save-analysis data to include arbitrary attribute data.
A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](https://github.com/rust-lang-nursery/rls/issues/173).
My changes contain:
1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs`
2. implement lowering for `Attribute` and `MetaItem`
3. adjust `JsonDumper` to print the attributes
In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`.
My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much.
Alex Crichton [Fri, 10 Mar 2017 22:51:12 +0000 (16:51 -0600)]
Rollup merge of #39202 - estebank:nested-unsafe, r=jonathandturner
Point to enclosing block/fn on nested unsafe
When declaring nested unsafe blocks (`unsafe {unsafe {}}`) that trigger
the "unnecessary `unsafe` block" error, point out the enclosing `unsafe
block` or `unsafe fn` that makes it unnecessary.
Alex Crichton [Mon, 6 Mar 2017 14:55:24 +0000 (06:55 -0800)]
Don't put Cargo into the rustc workspace
This causes problems when first cloning and bootstrapping the repository
unfortunately, so let's ensure that Cargo sticks around in its own workspace.
Because Cargo is a submodule it's not available by default on the inital clone
of the rust-lang/rust repository. Normally it's the responsibility of the
rustbuild to take care of this, but unfortunately to build rustbuild itself we
need to resolve the workspace conflicts.
To deal with this we'll just have to ensure that all submodules are in their own
workspace, which sort of makes sense anyway as updates to dependencies as
bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any
case this commit removes Cargo from the global workspace which should resolve
the issues that we've been seeing.
To actually perform this the `cargo` submodule has been moved to the top
directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace.
Petr Hosek [Fri, 17 Feb 2017 04:54:24 +0000 (20:54 -0800)]
travis: Fuchsia builder
This change introduces a Dockerfile and script which builds a complete
Fuchsia toolchain which can be used to build Rust distribution for
Fuchsia. We only support cross-compiling at the moment, hence only
setting the target.
Alex Crichton [Tue, 7 Mar 2017 23:15:55 +0000 (15:15 -0800)]
rustc: Exit quickly on only `--emit dep-info`
This commit alters the compiler to exit quickly if the only output being emitted
is `dep-info`, which doesn't need a lot of other information to generate.
In recent months there have been a few different people investigating how to make a plugin that
registers a MIR-pass – one that isn’t intended to be eventually merged into rustc proper.
The interface to register MIR passes was added primarily for miri (& later was
found to make prototyping of rustc-proper MIR passes a tiny bit faster). Since miri does not use
this interface anymore it seems like a good time to remove this "feature".
For prototyping purposes a similar interface can be added by developers themselves in their custom
rustc build.
Esteban Küber [Fri, 20 Jan 2017 07:17:48 +0000 (23:17 -0800)]
Point to enclosing block/fn on nested unsafe
When declaring nested unsafe blocks (`unsafe {unsafe {}}`) that trigger
the "unnecessary `unsafe` block" error, point out the enclosing `unsafe
block` or `unsafe fn` that makes it unnecessary.
bors [Fri, 10 Mar 2017 13:22:12 +0000 (13:22 +0000)]
Auto merge of #39518 - alexcrichton:update-cargo, r=arielb1
rustbuild: Use copies instead of hard links
The original motivation for hard links was to speed up the various stages of
rustbuild, but in the end this is causing problems on Windows (#39504).
This commit tweaks the build system to use copies instead of hard links
unconditionally to ensure that the files accessed by Windows are always
disjoint.
Locally this added .3s to a noop build, so it shouldn't be too much of a
regression hopefully!
bors [Thu, 9 Mar 2017 20:46:14 +0000 (20:46 +0000)]
Auto merge of #40382 - alexcrichton:split-tested-targets, r=brson
travis: Split the linux-tested-targets builder
Travis only gives us 30GB disk space and we don't currently have an option to
increase that. Each musl target generates "hello world" binaries of about 3.5MB
in size, and we're testing two targets in the same image. We have around 3k
run-pass tests and 2 musl targets which works out to around 20GB. That's
dangerously close to the limit and is causing PRs to bounce.
This PR splits up the builder in two, one for x86_64 musl and the other for
i686. Hopefully that'll keep us under the disk limit.
Alex Crichton [Thu, 9 Mar 2017 03:46:44 +0000 (19:46 -0800)]
travis: Split the linux-tested-targets builder
Travis only gives us 30GB disk space and we don't currently have an option to
increase that. Each musl target generates "hello world" binaries of about 3.5MB
in size, and we're testing two targets in the same image. We have around 3k
run-pass tests and 2 musl targets which works out to around 20GB. That's
dangerously close to the limit and is causing PRs to bounce.
This PR splits up the builder in two, one for x86_64 musl and the other for
i686. Hopefully that'll keep us under the disk limit.
Alex Crichton [Mon, 6 Mar 2017 22:44:38 +0000 (14:44 -0800)]
rustc: Prefer loading crates in the sysroot
This commit is a random stab in the dark to fix the spurious failures on #39518.
The leading theory of the spurious failures on Windows is that the compiler is
loading a path in the `deps` folder, passing it to `link.exe`, and then this is
racing with Cargo itself updating those paths.
This race, however, has a few unique properties:
* It's isolated to just libstd. Most crates are never passed to the linker and
simultaneously being worked on by Cargo. Cargo's typical execution of the
dependency graph never hits this problem.
* The crates are already all located in the sysroot in addition to the `deps`
folder. This means that the compiler actually has two candidates of crates to
load, and it's just arbitrarily rejecting one.
Together this means that we shouldn't need to fix this problem "in the large"
and we can instead just fix it in this isolated situation (hopefully). To solve
this the compiler's been updated to prefer crates from the sysroot to leave
Cargo's structure to itself.
We'll see if this actually allows the PR to land...
Alex Crichton [Sat, 4 Feb 2017 01:12:58 +0000 (17:12 -0800)]
rustbuild: Use copies instead of hard links
The original motivation for hard links was to speed up the various stages of
rustbuild, but in the end this is causing problems on Windows (#39504).
This commit tweaks the build system to use copies instead of hard links
unconditionally to ensure that the files accessed by Windows are always
disjoint.
Locally this added .3s to a noop build, so it shouldn't be too much of a
regression hopefully!
bors [Thu, 9 Mar 2017 06:06:34 +0000 (06:06 +0000)]
Auto merge of #40337 - alexcrichton:racy-dirs, r=brson
rustbuild: Assert directory creation succeeds
I've been seeing failures on the bots when building jemalloc and my assumption
is that it's because cwd isn't created. That may be possible if this
`create_dir_all` call change in this commit fails, in which case we ignore the
error.
This commit updates the location to call `create_dir_racy` which handles
concurrent invocations, as multiple build scripts may be trying to create the
`native` dir.
Rollup merge of #40268 - Mark-Simulacrum:normalization-followup, r=arielb1
Fix normalization error
Follows #40163. I don't know whether this is good, but seems logical.
[This block of code](https://github.com/rust-lang/rust/blob/ba07bd5d23aced6d4baa5696213b11ca832c1a5d/src/librustc_typeck/check/mod.rs#L2110-L2138) doesn't contain a call to `normalize_associated_types_in`, while [this](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/mod.rs#L2027-L2028) block does, and is nearly identical.
Ideally these two blocks should be unified into one, but since the change doesn't seem trivial and I'm unsure if this patch will be accepted it hasn't been done yet.
Rollup merge of #40254 - nagisa:compiler-builtin-no-panic, r=alexcrichton
Fix personality_fn within the compiler_builtins
compiler_builtins may not have any unwinding within it to link correctly. This is notoriously
finicky, and this small piece of change removes yet another case where personality function
happens to get introduced.
Side note: I do remember solving the exact same thing before. I wonder why it has reappered...
@cuviper, could you please try building beta with this patch applied? It should apply cleanly. If it works, I’ll nominate to land this into beta.
bors [Wed, 8 Mar 2017 09:30:13 +0000 (09:30 +0000)]
Auto merge of #39713 - estebank:issue-39698, r=jonathandturner
Clean up "pattern doesn't bind x" messages
Group "missing variable bind" spans in `or` matches and clarify wording
for the two possible cases: when a variable from the first pattern is
not in any of the subsequent patterns, and when a variable in any of the
other patterns is not in the first one.
Before:
```rust
error[E0408]: variable `a` from pattern #1 is not bound in pattern #2
--> file.rs:10:23
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `b` from pattern #2 is not bound in pattern #1
--> file.rs:10:32
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `b`
error[E0408]: variable `a` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error[E0408]: variable `c` from pattern #3 is not bound in pattern #1
--> file.rs:10:43
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `c`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #4
--> file.rs:10:48
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error: aborting due to 6 previous errors
```
After:
```rust
error[E0408]: variable `d` is not bound in all patterns
--> $DIR/issue-39698.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| - - ^^^^^^^^ ^^^^^^^^ pattern doesn't bind `d`
| | | |
| | | pattern doesn't bind `d`
| | variable not in all patterns
| variable not in all patterns
error[E0408]: variable `c` is not bound in all patterns
--> $DIR/issue-39698.rs:20:48
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^^^^ ^^^^^^^^^^^ - ^^^^^^^^ pattern doesn't bind `c`
| | | |
| | | variable not in all patterns
| | pattern doesn't bind `c`
| pattern doesn't bind `c`
error[E0408]: variable `a` is not bound in all patterns
--> $DIR/issue-39698.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| - ^^^^^^^^^^^ ^^^^^^^^ - variable not in all patterns
| | | |
| | | pattern doesn't bind `a`
| | pattern doesn't bind `a`
| variable not in all patterns
error[E0408]: variable `b` is not bound in all patterns
--> $DIR/issue-39698.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^^^^ - ^^^^^^^^ ^^^^^^^^ pattern doesn't bind `b`
| | | |
| | | pattern doesn't bind `b`
| | variable not in all patterns
| pattern doesn't bind `b`
Alex Crichton [Tue, 7 Mar 2017 23:24:36 +0000 (15:24 -0800)]
rustbuild: Assert directory creation succeeds
I've been seeing failures on the bots when building jemalloc and my assumption
is that it's because cwd isn't created. That may be possible if this
`create_dir_all` call change in this commit fails, in which case we ignore the
error.
This commit updates the location to call `create_dir_racy` which handles
concurrent invocations, as multiple build scripts may be trying to create the
`native` dir.
Esteban Küber [Fri, 10 Feb 2017 01:54:56 +0000 (17:54 -0800)]
Clean up "pattern doesn't bind x" messages
Group "missing variable bind" spans in `or` matches and clarify wording
for the two possible cases: when a variable from the first pattern is
not in any of the subsequent patterns, and when a variable in any of the
other patterns is not in the first one.
Before:
```
error[E0408]: variable `a` from pattern #1 is not bound in pattern #2
--> file.rs:10:23
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `b` from pattern #2 is not bound in pattern #1
--> file.rs:10:32
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `b`
error[E0408]: variable `a` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `a`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #3
--> file.rs:10:37
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error[E0408]: variable `c` from pattern #3 is not bound in pattern #1
--> file.rs:10:43
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^ pattern doesn't bind `c`
error[E0408]: variable `d` from pattern #1 is not bound in pattern #4
--> file.rs:10:48
|
10 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => { println!("{:?}", a); }
| ^^^^^^^^ pattern doesn't bind `d`
error: aborting due to 6 previous errors
```
After:
```
error[E0408]: variable `a` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| - ^^^^^^^^^^^ ^^^^^^^^ - variable
t in all patterns
| | | |
| | | pattern doesn't bind `a`
| | pattern doesn't bind `a`
| variable not in all patterns
error[E0408]: variable `d` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| - - ^^^^^^^^ ^^^^^^^^ pattern
esn't bind `d`
| | | |
| | | pattern doesn't bind `d`
| | variable not in all patterns
| variable not in all patterns
error[E0408]: variable `b` is not bound in all patterns
--> file.rs:20:37
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| ^^^^^^^^^^^ - ^^^^^^^^ ^^^^^^^^ pattern
esn't bind `b`
| | | |
| | | pattern doesn't bind `b`
| | variable not in all patterns
| pattern doesn't bind `b`
error[E0408]: variable `c` is not bound in all patterns
--> file.rs:20:48
|
20 | T::T1(a, d) | T::T2(d, b) | T::T3(c) | T::T4(a) => {
intln!("{:?}", a); }
| ^^^^^^^^^^^ ^^^^^^^^^^^ - ^^^^^^^^ pattern
esn't bind `c`
| | | |
| | | variable not in all
tterns
| | pattern doesn't bind `c`
| pattern doesn't bind `c`
error: aborting due to 4 previous errors
```
* Have only one presentation for binding consistency errors
* Point to same binding in multiple patterns when possible
* Check inconsistent bindings in all arms
* Simplify wording of diagnostic message
* Sort emition and spans of binding errors for deterministic output