kennytm [Sat, 16 Mar 2019 06:56:55 +0000 (14:56 +0800)]
Rollup merge of #59173 - emilio:llvm-suffix, r=Mark-Simulacrum
bootstrap: Default to a sensible llvm-suffix.
I used version-channel-sha, hopefully that should work.
I checked that bootstrap builds, but I cannot check anything else since the llvm
build process is started from cargo, and thus calls clang, and thus I hit the
same bug I hope to fix with this change.
kennytm [Sat, 16 Mar 2019 06:56:54 +0000 (14:56 +0800)]
Rollup merge of #59169 - tmandry:allow-features-flag, r=cramertj
Add `-Z allow_features=...` flag
Adds a compiler option to allow only whitelisted features.
For projects on nightly that want to prevent feature-creep (and maybe, someday, move off of nightly). Not being able to enforce this has been a problem on Fuchsia and at other big companies.
This doesn't support filtering edition feature flags, but someone is welcome to add that if they need it.
kennytm [Sat, 16 Mar 2019 06:56:53 +0000 (14:56 +0800)]
Rollup merge of #59158 - Manishearth:fix-minification, r=GuillaumeGomez
Revert "Don't generate minification variable if minification disabled"
Reverts #58643
Fixes #59157
https://github.com/rust-lang/rust/pull/58643 made us stop generating minification variables when minification is disabled, however they may still be needed for parent crates that were generated with minification (this will always be the case for libstd and libcore)
kennytm [Sat, 16 Mar 2019 06:56:51 +0000 (14:56 +0800)]
Rollup merge of #59156 - davidtwco:issue-55809, r=nikomatsakis
[wg-async-await] Add regression test for #55809.
Fixes #55809.
This PR adds a regression test for #55809 which checks that a
overflow does not occur when evaluating a requirement for async
functions and `&mut` arguments in some specific circumstances.
kennytm [Sat, 16 Mar 2019 06:56:50 +0000 (14:56 +0800)]
Rollup merge of #59152 - smmalis37:range_contains, r=SimonSapin
Stabilize Range*::contains.
Closes https://github.com/rust-lang/rust/issues/32311. There's also a bit of rustfmt on range.rs thrown in for good measure (I forgot to turn off format-on-save in VSCode).
kennytm [Sat, 16 Mar 2019 06:56:48 +0000 (14:56 +0800)]
Rollup merge of #59147 - jethrogb:jb/time-tests, r=sfackler
Make std time tests more robust for platform differences
Previously, `time::tests::since_epoch` and `time::tests::system_time_math` would fail if the platform represents a SystemTime as unix epoch + `u64` nanoseconds.
With [`num_traits::Float`](https://docs.rs/num-traits/0.2.6/num_traits/float/trait.Float.html) we could've reduced number of methods by factor of two, but unfortunately it's not part of `std`.
kennytm [Sat, 16 Mar 2019 06:56:33 +0000 (14:56 +0800)]
Rollup merge of #59037 - Manishearth:intra-doc-false, r=QuietMisdreavus
Avoid some common false positives in intra doc link checking
The empty string case is never going to be a link. The numeric case may be a link, but if it were it would have resolved locally. It's more likely the makeshift markdown footnote notation (`[0]`, etc)
kennytm [Sat, 16 Mar 2019 06:56:30 +0000 (14:56 +0800)]
Rollup merge of #59025 - aoikonomopoulos:issue-57924, r=varkor
Fix generic argument lookup for Self
Rewrite the SelfCtor early and use the replacement Def when
calculating the path_segs.
Note that this also changes which def is seen by the code that
computes user_self_ty and is_alias_variant_ctor; I don't see a
immediate issue with that, but I'm not 100% clear on the
implications.
kennytm [Sat, 16 Mar 2019 06:56:25 +0000 (14:56 +0800)]
Rollup merge of #58976 - phil-opp:patch-2, r=alexcrichton
Default to integrated `rust-lld` linker for UEFI targets
The `x86_64-unknown-uefi` target was added in https://github.com/rust-lang/rust/pull/56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.
I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:
- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)
cc @dvdhrm who added the target and @kkk669 who [proposed to use `rust-lld`](https://github.com/rust-lang/rust/pull/56769#issuecomment-461119648).
kennytm [Sat, 16 Mar 2019 06:56:23 +0000 (14:56 +0800)]
Rollup merge of #58949 - jethrogb:jb/sgx-thread-id, r=joshtriplett
SGX target: Expose thread id function in os module
In order to call `std::os::fortanix_sgx::usercalls::send`, you need the thread id. This exposes it through another function in `std::os::fortanix_sgx`.
I looked at how other platforms do this. On Windows and `cfg(unix)` you can get the OS handle from a `thread::JoinHandle`, but that's not sufficient, I need it for a `thread::Thread`. In the future, this functionality could be added to `thread::Thread` and this platform can follow suit.
kennytm [Sat, 16 Mar 2019 06:56:21 +0000 (14:56 +0800)]
Rollup merge of #58941 - wzssyqa:master, r=alexcrichton
MIPS: add r6 support
MIPS r6 is quite different with the previous version.
It use some new target triples:
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
This patch has been tested with Debian Port for mips64r6el,
and the support of these triples also is included in llvm:
https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
kennytm [Sat, 16 Mar 2019 06:56:18 +0000 (14:56 +0800)]
Rollup merge of #58933 - SimonSapin:alloc-prelude-v1, r=Amanieu
Move alloc::prelude::* to alloc::prelude::v1, make alloc a subset of std
This was one of the unresolved questions of https://github.com/rust-lang/rfcs/pull/2480. As the RFC says this is maybe not useful in the sense that we are unlikely to ever have a second version, but making the crate a true subset makes one less issue to think about if we stabilize it and later want to merge standard library crates and have Cargo feature flags to enable or disable parts of the `std` crate.
See also discussion in https://github.com/rust-lang/rust/pull/58175.
Also rename the feature gate and point to a dedicated tracking issue: https://github.com/rust-lang/rust/issues/58935
kennytm [Sat, 16 Mar 2019 06:56:16 +0000 (14:56 +0800)]
Rollup merge of #58901 - ebarnard:just-copying, r=sfackler
Change `std::fs::copy` to use `copyfile` on MacOS and iOS
`copyfile` on MacOS is similar to `CopyFileEx` on Windows. It supports copying resource forks, extended attributes, and file ACLs, none of which are copied by the current generic unix implementation.
The API is available from MacOS 10.7 and iOS 4.3 (and possibly earlier but I haven't checked).
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>