Rollup of 4 pull requests
Successful merges:
- #89889 (Use the "nice E0277 errors"[1] for `!Send` `impl Future` from foreign crate)
- #90127 (Do not mention a reexported item if it's private)
- #90143 (tidy: Remove submodules from edition exception list)
- #90238 (Add alias for guillaume.gomez@huawei.com)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not mention a reexported item if it's private
Fixes#90113
The _actual_ regression was introduced in #73652, then #88838 made it worse. This fixes the issue by not counting such an import as a candidate.
Use the "nice E0277 errors"[1] for `!Send` `impl Future` from foreign crate
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
r? `@tmandry`
Cleanup LLVM multi-threading checks
The support for runtime multi-threading was removed from LLVM. Calls to
`LLVMStartMultithreaded` became no-ops equivalent to checking if LLVM
was compiled with support for threads http://reviews.llvm.org/D4216.
Build the query vtable directly.
Continuation of https://github.com/rust-lang/rust/pull/89978.
This shrinks the query interface and attempts to reduce the amount of function pointer calls.
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
1. The existing example compiles on its own, but any usage fails
to be monomorphised and so doesn't compile. Fix that by using
a mutable reference as an input argument.
2. Added an example usage of `traverse_inorder` showing how we
can terminate the traversal early.
Fixes#90063
Temporarily turn overflow checks off for rustc-rayon-core
The rustc fork of Rayon has deadlock detection code which intermittently causes overflows in the CI (see https://github.com/rust-lang/rust/issues/90227). So, as a workaround, we unconditionally turn overflow checks off for this crate only.
This workaround should be removed once #90227 is fixed.
r? `@Mark-Simulacrum`
cc `@matthiaskrgr`
Fix ICE when forgetting to `Box` a parameter to a `Self::func` call
Closes#90213 .
Assuming we can get the `DefId` of the receiver causes an ICE if the receiver is `Self`. We can just avoid doing this though.
Skip documentation for tier 2 targets on dist-x86_64-apple-darwin
I don't have an easy way to test this locally, but I believe it should work. Based on one log result should shave ~14 minutes off the dist-x86_64-apple builder (doesn't help with aarch64 dist or x86_64 test builder, so not actually decreasing total CI time most likely).
r? ```@pietroalbini```
Specialize HashStable for [u8] slices
Particularly for ctfe-stress-4, the hashing of byte slices as part of the
MIR Allocation is quite hot. Previously, we were falling back on byte-by-byte
copying of the slice into the SipHash buffer (64 bytes long) before hashing a 64
byte chunk, and then doing that again and again; now we use the dedicated byte-slice write.
CI: Enable overflow checks for test (non-dist) builds
They stay disabled for Apple builds though, which take the most time already due to running on slow hw.
Update the minimum external LLVM to 12
With this change, we'll have stable support for LLVM 12 and 13.
For reference, the previous increase to LLVM 10 was #83387,
and this replaces the pending increase to LLVM 11 in #90062.
r? `@nagisa` `@nikic`
Particularly for ctfe-stress-4, the hashing of byte slices as part of the
MIR Allocation is quite hot. Previously, we were falling back on byte-by-byte
copying of the slice into the SipHash buffer (64 bytes long) before hashing a 64
byte chunk, and then doing that again and again.
This should hopefully be an improvement for that code.
Rollup of 5 pull requests
Successful merges:
- #85833 (Scrape code examples from examples/ directory for Rustdoc)
- #88041 (Make all proc-macro back-compat lints deny-by-default)
- #89829 (Consider types appearing in const expressions to be invariant)
- #90168 (Reset qualifs when a storage of a local ends)
- #90198 (Add caveat about changing parallelism and function call overhead)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Reset qualifs when a storage of a local ends
Reset qualifs when a storage of a local ends to ensure that the local qualifs
are affected by the state from previous loop iterations only if the local is
kept alive.
The change should be forward compatible with a stricter handling of indirect
assignments, since storage dead invalidates all existing pointers to the local.
Consider types appearing in const expressions to be invariant
This is an approach to fix#80977.
Currently, a type parameter which is only used in a constant expression is considered bivariant and will trigger error E0392 *"parameter T is never used"*.
Here is a short example:
```rust
pub trait Foo {
const N: usize;
}
struct Bar<T: Foo>([u8; T::N])
where [(); T::N]:;
```
([playgound](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=b51a272853f75925e72efc1597478aa5))
While it is possible to silence this error by adding a `PhantomData<T>` field, I think the better solution would be to make `T` invariant.
This would be analogous to the invariance constraints added for associated types.
However, I'm quite new to the compiler and unsure whether this is the right approach.
r? ``@varkor`` (since you authored #60058)
Make all proc-macro back-compat lints deny-by-default
The affected crates have had plenty of time to update.
By keeping these as lints rather than making them hard errors,
we ensure that downstream crates will still be able to compile,
even if they transitive depend on broken versions of the affected
crates.
This should hopefully discourage anyone from writing any
new code which relies on the backwards-compatibility behavior.
