kennytm [Sat, 16 Mar 2019 06:56:13 +0000 (14:56 +0800)]
Rollup merge of #58855 - alexcrichton:wasm-multithreaded-alloc, r=fitzgen
std: Spin for a global malloc lock on wasm32
There's lots of comments in the code, but the main gist of this commit
is that the acquisition of the global malloc lock on the
`wasm32-unknown-unknown` target when threads are enabled will not spin
on contention rather than block.
kennytm [Sat, 16 Mar 2019 06:56:11 +0000 (14:56 +0800)]
Rollup merge of #58854 - alexcrichton:update-windows, r=Mark-Simulacrum
appveyor: Use VS2017 for all our images
Originally added in #55935 to test build times, this was reverted
in #56201 due to a belief that it caused the exit code 259 spurious
errors. We've since learned, however, that the 259 exit code is likely
not related to this image update as we're getting it in a number of
locations now.
VS2017 looks like it may be required to compile LLVm in the near future,
notably discovered by #58408 where we attempted to update LLVM.
bors [Fri, 15 Mar 2019 13:58:03 +0000 (13:58 +0000)]
Auto merge of #58140 - eddyb:advent-of-print, r=nikomatsakis
Refactor ppaux out of existence.
A long-time coming, this PR reorganizes and rewrites the pretty-printing architecture of rustc, specifically the parts that involve the typesystem (which used to be in `rustc::util::ppaux`).
*Note: these commits used to be in #57967 before being split off.*
The new API (i.e. the `Printer` and `PrettyPrint` traits) is in `rustc::ty::print`.
Design points, roughly:
* using associated types in `Printer` to allow building e.g. an AST, not just printing as a side-effect
* several overloading points for implementers of `PrettyPrinter`, e.g. how `<...>` is printed
* for `fmt::Display` impls, the value to print is lifted to the `ty::tls` `tcx`, and everything after that stays within the `ty::print` API, which requires `'tcx` to match between values and the printer's `tcx`, without going through `fmt::Display` again
Most of the behavior is unchanged, except for a few details, which should be clear from the test changes.
bors [Fri, 15 Mar 2019 11:00:13 +0000 (11:00 +0000)]
Auto merge of #58575 - mati865:musl_toolchain, r=alexcrichton
Musl host toolchain
Based on https://github.com/rust-lang/rust/pull/55163 and https://github.com/rust-lang/rust/pull/57359
Depends on https://github.com/rust-lang/rust/pull/55566
CC https://github.com/rust-lang/rust/issues/57439
### How it works
Tested compiler made by `dist` on glibc and musl based distributions and verified binaries it produces:
* Ubuntu (glibc) - installed it as a target for host toolchain and observed no regressions for static (default) linking, dynamic linking apparently requires musl build libgcc so I didn't test it.
* Alpine (musl) - installed as the host toolchain, by default it links statically (executables are portable and work on glibc distributions) but with `-C target-feature=-crt-static` Rust flag it links dynamically (executables require musl built libraries).
### What's debatable
It should be decided whether this toolchain should link dynamically or statically when using it on musl distribution. I believe the distributions would prefer dynamic linking but it'd be misleading because `$ARCH-unknown-linux-musl` target links statically on the other hosts.
Another problem is using `RUSTFLAGS='-C target-feature=-crt-static'` for dynamic builds which is really uncomfortable.
To address both issues I suggest leaving `$ARCH-unknown-linux-musl` static for both host and cross target and introducing "alias triple" `$ARCH-unknown-linux-dynmusl`. It'd be the same as `$ARCH-unknown-linux-musl` (and use the same libraries to avoid duplication) but it'd link dynamically.
<del>
### Why it's still WIP (help wanted)
I'm having a hard time getting all tests to pass and I'd appreciate help.
For more information about this error, try `rustc --explain E0463`.
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
[RUSTC-TIMING] proc_macro test:true 0.529
[RUSTC-TIMING] proc_macro test:false 0.530
error: Could not compile `proc_macro`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `proc_macro`.
To learn more, run the command again with --verbose.
I think the error is because build system (correctly?) tries to use `obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps` which is empty but `obj/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-musl/release/deps` contains required libs.
</del>
Jonathan Sieber [Thu, 18 Oct 2018 19:47:26 +0000 (21:47 +0200)]
Set RUSTFLAGS env to make dylib work
The musl-target doesn't automatically disable static linking of musl when building a dylib, and then complains it can't build a dylib.
As a workaround, disable static linking via RUSTFLAGS, to see how far the build gets.
The proper fix is to have rustc figure that out automagically.
bors [Wed, 13 Mar 2019 18:26:45 +0000 (18:26 +0000)]
Auto merge of #59143 - ehuss:update-cargo, r=ehuss
Update cargo
6 commits in 95b45eca19ac785263fed98ecefe540bb47337ac..0e35bd8af0ec72d3225c4819b330b94628f0e9d0
2019-03-06 19:24:30 +0000 to 2019-03-13 06:52:51 +0000
- Make `hg` optional for tests. (rust-lang/cargo#6739)
- Fingerprint build script deps only for path packages. (rust-lang/cargo#6734)
- Add --quiet option for `cargo test` (rust-lang/cargo#6358)
- .gitignore should end with a newline. (rust-lang/cargo#6732)
- Emit warning on misspelled environment variables (rust-lang/cargo#6694)
- Update glob requirement from 0.2.11 to 0.3.0 (rust-lang/cargo#6724)
bors [Wed, 13 Mar 2019 14:59:05 +0000 (14:59 +0000)]
Auto merge of #58349 - petrochenkov:uni201x, r=pnkfelix
resolve: Simplify import resolution for mixed 2015/2018 edition mode
Non-controversial part of https://github.com/rust-lang/rust/pull/57745.
Before:
| Local edition (per-span) | Global edition (--edition) | Imports (`use foo;`) | Absolute paths (`::foo`) |
| ------------- |----------------|-----------------------------------------|------------------------------------------------|
| 2018 | Any | Uniform | Extern prelude |
| 2015 | 2015 | Crate-relative | Crate-relative |
| 2015 | 2018 | Crate-relative with fallback to Uniform (future-proofed to error if the result is not Crate-relative or from Extern prelude) | Crate-relative with fallback to Extern prelude |
After:
| Local edition (per-span) | Global edition (--edition) | Imports (`use foo;`) | Absolute paths (`::foo`) |
| ------------- |----------------|-----------------------------------------|------------------------------------------------|
| 2018 | Any | Uniform | Extern prelude |
| 2015 | 2015 | Crate-relative | Crate-relative |
| 2015 | 2018 | Crate-relative with fallback to Extern prelude | Crate-relative with fallback to Extern prelude |
I.e. only the behavior of the mixed local-2015-global-2018 mode is changed.
This mixed mode has two goals:
- Address regressions from https://github.com/rust-lang/rust/pull/56053#issuecomment-440826397.
Both "before" and "after" variants address those regressions.
- Be retrofit-able to "full 2015" edition (https://github.com/rust-lang/rust/pull/57745).
Any more complex fallback scheme (with more candidates) than "Crate-relative with fallback to Extern prelude" will give more regressions than https://github.com/rust-lang/rust/pull/57745#issuecomment-455855089 and is therefore less retrofit-able while also being, well, more complex.
So, we can settle on "Crate-relative with fallback to Extern prelude".
(I'll hopefully proceed with https://github.com/rust-lang/rust/pull/57745 after mid-February.)