Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````
I'd like to get the fix for https://github.com/rust-lang/cargo/issues/8223 into nightly asap.
bors [Sat, 9 May 2020 06:26:57 +0000 (06:26 +0000)]
Auto merge of #71994 - jyn514:path-independent, r=Mark-Simulacrum
x.py: allow configuring the build directory
This allows configuring the directory for build artifacts, instead of having it always be `./build`. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in `config.toml` under `build.build-dir`. By default, it keeps the existing default of `./build`, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using `$ROOT`.
Dylan DPC [Sat, 9 May 2020 01:10:09 +0000 (03:10 +0200)]
Rollup merge of #71942 - nnethercote:shrink-LocalDecl, r=matthewjasper
Shrink `LocalDecl`
`LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit, and does some clean-ups as well.
Dylan DPC [Sat, 9 May 2020 01:10:01 +0000 (03:10 +0200)]
Rollup merge of #70834 - yoshuawuyts:future-pending-ready, r=sfackler
Add core::future::{pending,ready}
Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.
These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.
## Examples
In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:
```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;
pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
let mut fut = future::ready(42_u8);
let num = ready!(Pin::new(fut).poll(cx));
// ... use num
Poll::Ready(())
}
```
## Why future::ready?
Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).
The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.
Joshua Nelson [Thu, 7 May 2020 20:51:03 +0000 (16:51 -0400)]
x.py: allow configuring the build directory
This allows configuring the directory for build artifacts, instead of having it always be ./build. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in config.toml under build.build-dir. By default, it keeps the existing default of ./build, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using $ROOT.
Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````
bors [Fri, 8 May 2020 20:03:23 +0000 (20:03 +0000)]
Auto merge of #72021 - Dylan-DPC:rollup-1w61ihk, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #71581 (Unify lints handling in rustdoc)
- #71710 (Test for zero-sized function items not ICEing)
- #71970 (Improve bitcode generation for Apple platforms)
- #71975 (Reduce `TypedArena` creations in `check_match`.)
- #72003 (allow wasm target for rustc-ap-rustc_span)
- #72017 (Work around ICEs during cross-compilation for target, ast, & attr)
Dylan DPC [Fri, 8 May 2020 16:48:33 +0000 (18:48 +0200)]
Rollup merge of #72017 - ctaggart:wasm2, r=ecstatic-morse
Work around ICEs during cross-compilation for target, ast, & attr
This applies the fix for #72003 to work around #56935 to three more libraries. With these additional fixes, I'm able to use rustfmt_lib from wasm (https://github.com/rust-lang/rustfmt/issues/4132#issuecomment-616587989), which was my goal.
To get it working locally and to test, I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project:
``` toml
[replace]
"rustc-ap-rustc_span:656.0.0" = { path = "../rustc-ap-rustc_span" }
"rustc-ap-rustc_target:656.0.0" = { path = "../rustc-ap-rustc_target" }
"rustc-ap-rustc_ast:656.0.0" = { path = "../rustc-ap-rustc_ast" }
"rustc-ap-rustc_attr:656.0.0" = { path = "../rustc-ap-rustc_attr" }
```
Dylan DPC [Fri, 8 May 2020 16:48:31 +0000 (18:48 +0200)]
Rollup merge of #72003 - ctaggart:wasm, r=jonas-schievink
allow wasm target for rustc-ap-rustc_span
This fixes #71998 by applying the work-a-round. The root cause is probably #56935, as @petrochenkov pointed out.
I reproduced the bug by:
```
cd ~/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-ap-rustc_span-657.0.0/
cargo build --target wasm32-unknown-unknown
```
Dylan DPC [Fri, 8 May 2020 16:48:29 +0000 (18:48 +0200)]
Rollup merge of #71975 - nnethercote:reduce-TypedArena-creations-in-check_match, r=oli-obk
Reduce `TypedArena` creations in `check_match`.
`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.
This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)
Dylan DPC [Fri, 8 May 2020 16:48:28 +0000 (18:48 +0200)]
Rollup merge of #71970 - thombles:ios-bitcode-improvements, r=alexcrichton
Improve bitcode generation for Apple platforms
Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton
This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).
1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.
In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.
Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
bors [Fri, 8 May 2020 13:11:43 +0000 (13:11 +0000)]
Auto merge of #72010 - Dylan-DPC:rollup-prdj0pk, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #71989 (Use a single enum for the kind of a const context)
- #71993 (Remove old `util/liveness.rs` module)
- #71999 (Add myself to mailmap.)
- #72001 (Adjust cfg(version) to lang team decision)
- #72007 (Fix some tests failing in `--pass check` mode)
- #72008 (Add const-generics test)
Dylan DPC [Fri, 8 May 2020 12:11:45 +0000 (14:11 +0200)]
Rollup merge of #71993 - ecstatic-morse:cleanup-old-liveness, r=jonas-schievink
Remove old `util/liveness.rs` module
The liveness dataflow analysis now lives in the `dataflow` module, so this one is no longer necessary. I've copied the relevant bits of the module docs for `util::liveness` to `MaybeLiveLocals`. The example in the docs is now a `mir-dataflow` test: https://github.com/rust-lang/rust/blob/a08c47310c7d49cbdc5d7afb38408ba519967ecd/src/test/ui/mir-dataflow/liveness-ptr.rs#L6-L26
The borrow-checker used the same notion of "defs" and "uses", so I've moved it into a submodule. I would have moved it to `util/def_use.rs`, since it seems generally useful, but there's already a slightly [different version](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/util/def_use.rs) of the same abstraction needed for copy propagation.
Dylan DPC [Fri, 8 May 2020 12:11:44 +0000 (14:11 +0200)]
Rollup merge of #71989 - ecstatic-morse:const-context-enum, r=oli-obk
Use a single enum for the kind of a const context
This adds a `ConstContext` enum to the `rustc_hir` crate and method that can be called via `tcx.hir()` to get the `ConstContext` for a given body owner. This arose from discussion in #71824.
bors [Fri, 8 May 2020 07:29:42 +0000 (07:29 +0000)]
Auto merge of #71917 - RalfJung:miri, r=RalfJung
update miri
In particular this includes the change to yield on `spin_loop_hint`, which is needed for https://github.com/rust-lang/rust/pull/71737.
r? @ghost Cc @rust-lang/miri
bors [Thu, 7 May 2020 21:52:39 +0000 (21:52 +0000)]
Auto merge of #71995 - pietroalbini:ci-windows-detect-latest-python, r=Mark-Simulacrum
[CI] Use the latest Python available on Windows
This PR changes our Windows CI to always use the latest Python interpreter available in the GHA tool cache instead of hardcoding Python 3.7.6. This is needed because occasionally GitHub bumps the installed version, deleting the previous one.
This fixes the current GHA outage we're having. I fully expect the outage to propagate to Azure Pipelines in the coming days if we don't merge this, as both GHA and Azure use the same underlying image. Once the PR is merged we can re-enabled the double-gating.
Pietro Albini [Thu, 7 May 2020 21:12:13 +0000 (23:12 +0200)]
ci: use the latest python available on windows
This commit changes our Windows CI to always use the latest Python
interpreter available in the GHA tool cache instead of hardcoding Python
3.7.6. This is needed because occasionally GitHub bumps the installed
version, deleting the previous one.
Dylan MacKenzie [Thu, 7 May 2020 19:55:01 +0000 (12:55 -0700)]
Remove old `util/liveness.rs` module
The liveness dataflow analysis now lives in
`librustc_mir/dataflow/impls/liveness.rs`. The borrow-checker has an
abstraction around of "defs" and "uses" that I've made module private. I
would have moved it to `util/def_use.rs`, but there's a slightly
different abstraction used for copy propagation with that name.
Dylan DPC [Thu, 7 May 2020 19:46:14 +0000 (21:46 +0200)]
Rollup merge of #71903 - euclio:reword-possible-better, r=petrochenkov
reword "possible candidate" import suggestion
This suggestion has always read a bit awkwardly to me, particularly the "possible better candidate" variant.
This commit rewords the suggestion to be more concise and mention the kind of the suggested item. There isn't a nice way to label individual suggestions, so I opted to use "items" in the case of multiple suggestions.
Dylan DPC [Thu, 7 May 2020 19:46:06 +0000 (21:46 +0200)]
Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount, r=Mark-Simulacrum
Add Arc::{incr,decr}_strong_count
This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064, and from asking a few people this seemed like generally useful to have.
References:
- [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064)
- [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13)
Dylan DPC [Thu, 7 May 2020 15:59:00 +0000 (17:59 +0200)]
Rollup merge of #71980 - steveklabnik:warnings-fixes, r=Mark-Simulacrum
Allow a few warnings.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
Dylan DPC [Thu, 7 May 2020 15:58:59 +0000 (17:58 +0200)]
Rollup merge of #71972 - RalfJung:miri-validity-error-refine, r=oli-obk
use hex for pointers in Miri error messages
Also refine vtable error message: distinguish between "drop fn does not point to a function" and "drop fn points to a function with the wrong signature".
Steve Klabnik [Thu, 7 May 2020 12:23:06 +0000 (07:23 -0500)]
Allow a few warnings.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
bors [Thu, 7 May 2020 09:47:49 +0000 (09:47 +0000)]
Auto merge of #71649 - ecstatic-morse:ci-stage0-doc, r=Mark-Simulacrum
Ensure that `./x.py doc --stage 0 src/libstd` works via CI
This was split off from #71645, which recommends that users first try building `libstd` docs with the bootstrap `rustdoc`. This should work in most cases, but will fail if we start using a very recent `rustdoc` feature outside a `#[cfg(not(bootstrap))]`.
It would be very nice to guarantee that `./x.py doc --stage 0 src/libstd` works, since it allows documentation changes to be rendered locally without needing to build the compiler. However, it may put too big a burden on `rustdoc` developers who presumably want to dogfood new features.
Tom Karpiniec [Thu, 7 May 2020 05:34:31 +0000 (15:34 +1000)]
Provide configurable LLVM cmdline section via target spec
The App Store performs certain sanity checks on bitcode, including that
an acceptable set of command line arguments was used when compiling a
given module. For Rust code to be distributed on the app store with
bitcode rustc must pretend to have the same command line arguments.
Tom Karpiniec [Thu, 7 May 2020 02:26:18 +0000 (12:26 +1000)]
Force embed-bitcode on non-simulator iOS/tvOS targets
At this time Apple recommends Bitcode be included for iOS apps, and
requires it for tvOS. It is unlikely that a developer would want to
disable bitcode when building for these targets, yet by default it will
not be generated. This presents a papercut for developers on those
platforms.
Introduces a new TargetOption boolean key for specific triples to
indicate that bitcode should be generated, even if cargo attempts to
optimise with -Cembed-bitcode=no.
`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.
This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)
bors [Thu, 7 May 2020 00:03:23 +0000 (00:03 +0000)]
Auto merge of #55617 - oli-obk:stacker, r=nagisa,oli-obk
Prevent compiler stack overflow for deeply recursive code
I was unable to write a test that
1. runs in under 1s
2. overflows on my machine without this patch
The following reproduces the issue, but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`.
macro_rules! chain {
(EE $e:expr) => {$e.sin()};
(RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))};
(Z $e:expr) => {chain!(RECURSE EE $e)};
(Y $e:expr) => {chain!(RECURSE Z $e)};
(X $e:expr) => {chain!(RECURSE Y $e)};
(A $e:expr) => {chain!(RECURSE X $e)};
(B $e:expr) => {chain!(RECURSE A $e)};
(C $e:expr) => {chain!(RECURSE B $e)};
// causes overflow on x86_64 linux
// less than 1 second until overflow on test machine
// after overflow has been fixed, takes 30s to compile :/
(D $e:expr) => {chain!(RECURSE C $e)};
(E $e:expr) => {chain!(RECURSE D $e)};
(F $e:expr) => {chain!(RECURSE E $e)};
// more than 10 seconds
(G $e:expr) => {chain!(RECURSE F $e)};
(H $e:expr) => {chain!(RECURSE G $e)};
(I $e:expr) => {chain!(RECURSE H $e)};
(J $e:expr) => {chain!(RECURSE I $e)};
(K $e:expr) => {chain!(RECURSE J $e)};
(L $e:expr) => {chain!(RECURSE L $e)};
}
Dylan DPC [Wed, 6 May 2020 20:36:55 +0000 (22:36 +0200)]
Rollup merge of #71950 - RalfJung:try-validation-cleanup, r=oli-obk
Miri validation error handling cleanup
Slightly expand @jumbatm's pattern macro and use it throughout validation. This ensures we never incorrectly swallow `InvalidProgram` errors or ICE when they occur.
It renames the section [methods](https://doc.rust-lang.org/nightly/std/string/struct.String.html#methods) into "Implementations". However, I didn't not update the title in the sidebar considering that it only lists methods under (even though I updated the link of the "methods" to make it point to the "implementations" section.
Dylan DPC [Wed, 6 May 2020 20:36:45 +0000 (22:36 +0200)]
Rollup merge of #71731 - mark-i-m:guide-toolstate-off-for-now, r=kennytm
Turn off rustc-dev-guide toolstate for now
cc @rust-lang/wg-rustc-dev-guide @rust-lang/infra @ehuss
When we first added toolstate, the intent was to use toolstate to linkcheck PRs so that we would know which PRs break links in the guide (e.g. by moving some definition). However, these days, we are mostly getting 429 errors (too many requests) from github (not sure when this changed), and every day, there seems to be a spurious failure of some other sort. This is all despite efforts to filter out spurious failures.
Getting spurious gh pings is annoying, and we're not actually getting a lot out of this linkcheck beyond what we are getting with our CI on the guide's repo, so I'm proposing to disable this until we can figure out what might be a better path forward.
Dylan DPC [Wed, 6 May 2020 20:36:43 +0000 (22:36 +0200)]
Rollup merge of #70908 - estebank:suggest-add, r=nikomatsakis
Provide suggestions for type parameters missing bounds for associated types
When implementing the binary operator traits it is easy to forget to restrict the `Output` associated type. `rustc` now accounts for different cases to lead users in the right direction to add the necessary restrictions. The structured suggestions in the following output are new:
```
error: equality constraints are not yet supported in `where` clauses
--> $DIR/missing-bounds.rs:37:33
|
LL | impl<B: Add> Add for E<B> where <B as Add>::Output = B {
| ^^^^^^^^^^^^^^^^^^^^^^ not supported
|
= note: see issue #20041 <https://github.com/rust-lang/rust/issues/20041> for more information
help: if `Output` is an associated type you're trying to set, use the associated type binding syntax
|
LL | impl<B: Add> Add for E<B> where B: Add<Output = B> {
| ^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> $DIR/missing-bounds.rs:11:11
|
7 | impl<B> Add for A<B> where B: Add {
| - this type parameter
...
11 | A(self.0 + rhs.0)
| ^^^^^^^^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<B as std::ops::Add>::Output`
help: consider further restricting this bound
|
7 | impl<B> Add for A<B> where B: Add + std::ops::Add<Output = B> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0369]: cannot add `B` to `B`
--> $DIR/missing-bounds.rs:31:21
|
31 | Self(self.0 + rhs.0)
| ------ ^ ----- B
| |
| B
|
help: consider restricting type parameter `B`
|
27 | impl<B: std::ops::Add<Output = B>> Add for D<B> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
That output is given for the following cases:
```rust
struct A<B>(B);
impl<B> Add for A<B> where B: Add {
type Output = Self;
bors [Wed, 6 May 2020 16:59:45 +0000 (16:59 +0000)]
Auto merge of #71951 - Dylan-DPC:rollup-j9v1p0f, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #71269 (Define UB in float-to-int casts to saturate)
- #71591 (use new interface to create threads on HermitCore)
- #71819 (x.py: Give a more helpful error message if curl isn't installed)
- #71893 (Use the `impls` module to import pre-existing dataflow analyses)
- #71929 (Use -fvisibility=hidden for libunwind)
- #71937 (Ignore SGX on a few ui tests)
- #71944 (Add comment for `Ord` implementation for array)