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
bors [Sun, 5 Mar 2017 19:53:29 +0000 (19:53 +0000)]
Auto merge of #40266 - Mark-Simulacrum:cleanup-parser, r=petrochenkov
Inline function to avoid naming confusion.
Fixes the non-RFC requiring portion of #18394. The suggestion for a new token there probably needs to either be refiled onto rust-lang/rfcs if it's still relevant (may not be given Macros 2.0 work, not sure).
bors [Sat, 4 Mar 2017 15:40:10 +0000 (15:40 +0000)]
Auto merge of #40213 - steveklabnik:extract-reference, r=alexcrichton
Move the reference into a submodule
Part of https://github.com/rust-lang/rust/issues/39588
This moves the reference out into its own submodule. Right now, it's under my own account; I would assume that it should go under `rust-lang`, but I guess there's an argument for the nursery too? I can fix that up before we commit it.
bors [Sat, 4 Mar 2017 12:33:35 +0000 (12:33 +0000)]
Auto merge of #40245 - cuviper:maybe-not-pie, r=alexcrichton
Let `-Crelocation-model` better control `-pie` linking
Prior to this, if relocation model in the target options was "pic", as
most targets have it, then the user's `-Crelocation-model` had no effect
on whether `-pie` would be used. Only `-Clink-arg=-static` would have a
further override here.
Now we use `context::get_reloc_model`, which gives precedence to the
user's option, and if it's `RelocMode::PIC` we enable `-pie`. This is
the same test as `context::is_pie_binary`, except that folds across all
`sess.crate_types`, not just the current one.
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...
bors [Fri, 3 Mar 2017 23:26:26 +0000 (23:26 +0000)]
Auto merge of #39917 - alexcrichton:build-cargo, r=brson
rustbuild: Add support for compiling Cargo
This commit adds support to rustbuild for compiling Cargo as part of the release
process. Previously rustbuild would simply download a Cargo snapshot and
repackage it. With this change we should be able to turn off artifacts from the
rust-lang/cargo repository and purely rely on the artifacts Cargo produces here.
The infrastructure added here is intended to be extensible to other components,
such as the RLS. It won't exactly be a one-line addition, but the addition of
Cargo didn't require too much hooplah anyway.
The process for release Cargo will now look like:
* The rust-lang/rust repository has a Cargo submodule which is used to build a
Cargo to pair with the rust-lang/rust release
* Periodically we'll update the cargo submodule as necessary on rust-lang/rust's
master branch
* When branching beta we'll create a new branch of Cargo (as we do today), and
the first commit to the beta branch will be to update the Cargo submodule to
this exact revision.
* When branching stable, we'll ensure that the Cargo submodule is updated and
then make a stable release.
Backports to Cargo will look like:
* Send a PR to cargo's master branch
* Send a PR to cargo's release branch (e.g. rust-1.16.0)
* Send a PR to rust-lang/rust's beta branch updating the submodule
* Eventually send a PR to rust-lang/rust's master branch updating the submodule
For reference, the process to add a new component to the rust-lang/rust release
would look like:
* Add `$foo` as a submodule in `src/tools`
* Add a `tool-$foo` step which compiles `$foo` with the specified compiler,
likely mirroring what Cargo does.
* Add a `dist-$foo` step which uses `src/tools/$foo` and the `tool-$foo` output
to create a rust-installer package for `$foo` likely mirroring what Cargo
does.
* Update the `dist-extended` step with a new dependency on `dist-$foo`
* Update `src/tools/build-manifest` for the new component.
Josh Stone [Fri, 3 Mar 2017 19:39:11 +0000 (11:39 -0800)]
Let `-Crelocation-model` better control `-pie` linking
Prior to this, if relocation model in the target options was "pic", as
most targets have it, then the user's `-Crelocation-model` had no effect
on whether `-pie` would be used. Only `-Clink-arg=-static` would have a
further override here.
Now we use `context::get_reloc_model`, which gives precedence to the
user's option, and if it's `RelocMode::PIC` we enable `-pie`. This is
the same test as `context::is_pie_binary`, except that folds across all
`sess.crate_types`, not just the current one.
Alex Crichton [Wed, 15 Feb 2017 23:57:06 +0000 (15:57 -0800)]
rustbuild: Add support for compiling Cargo
This commit adds support to rustbuild for compiling Cargo as part of the release
process. Previously rustbuild would simply download a Cargo snapshot and
repackage it. With this change we should be able to turn off artifacts from the
rust-lang/cargo repository and purely rely on the artifacts Cargo produces here.
The infrastructure added here is intended to be extensible to other components,
such as the RLS. It won't exactly be a one-line addition, but the addition of
Cargo didn't require too much hooplah anyway.
The process for release Cargo will now look like:
* The rust-lang/rust repository has a Cargo submodule which is used to build a
Cargo to pair with the rust-lang/rust release
* Periodically we'll update the cargo submodule as necessary on rust-lang/rust's
master branch
* When branching beta we'll create a new branch of Cargo (as we do today), and
the first commit to the beta branch will be to update the Cargo submodule to
this exact revision.
* When branching stable, we'll ensure that the Cargo submodule is updated and
then make a stable release.
Backports to Cargo will look like:
* Send a PR to cargo's master branch
* Send a PR to cargo's release branch (e.g. rust-1.16.0)
* Send a PR to rust-lang/rust's beta branch updating the submodule
* Eventually send a PR to rust-lang/rust's master branch updating the submodule
For reference, the process to add a new component to the rust-lang/rust release
would look like:
* Add `$foo` as a submodule in `src/tools`
* Add a `tool-$foo` step which compiles `$foo` with the specified compiler,
likely mirroring what Cargo does.
* Add a `dist-$foo` step which uses `src/tools/$foo` and the `tool-$foo` output
to create a rust-installer package for `$foo` likely mirroring what Cargo
does.
* Update the `dist-extended` step with a new dependency on `dist-$foo`
* Update `src/tools/build-manifest` for the new component.
bors [Fri, 3 Mar 2017 09:57:57 +0000 (09:57 +0000)]
Auto merge of #40189 - SimonSapin:one-width, r=alexcrichton
Reduce std_unicodeās public API
* Only keep one copy of the `UTF8_CHAR_WIDTH` table instead of one of each of libcore and libstd_unicode.
* Move the `utf8_char_width` function to `core::str` under the `str_internals` unstable feature.
* Remove `std_unicode::str::is_utf16`. It was only accessible through the `#[unstable]` crate std_unicode. It has never been used in the compiler or standard library since 47e7a05 added it in 2012 āfor OS API interopā. It can be replaced with a one-liner:
projects / rust.git / log