bors [Mon, 25 Oct 2021 08:22:07 +0000 (08:22 +0000)]
Auto merge of #90249 - matthiaskrgr:rollup-xwtfhq3, r=matthiaskrgr
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)
Matthias Krüger [Mon, 25 Oct 2021 05:54:13 +0000 (07:54 +0200)]
Rollup merge of #90127 - JohnTitor:fix-90113, r=estebank
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.
Matthias Krüger [Mon, 25 Oct 2021 05:54:12 +0000 (07:54 +0200)]
Rollup merge of #89889 - estebank:unmet-send-bound-on-foreign-future, r=tmandry
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.
bors [Mon, 25 Oct 2021 05:28:07 +0000 (05:28 +0000)]
Auto merge of #89808 - tmiasko:llvm-multithreaded, r=nagisa
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.
Esteban Kuber [Thu, 14 Oct 2021 17:57:39 +0000 (17:57 +0000)]
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.
bors [Sun, 24 Oct 2021 14:12:10 +0000 (14:12 +0000)]
Auto merge of #90235 - matthiaskrgr:rollup-7pqtevk, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #89558 (Add rustc lint, warning when iterating over hashmaps)
- #90100 (Skip documentation for tier 2 targets on dist-x86_64-apple-darwin)
- #90155 (Fix alignment of method headings for scannability)
- #90162 (Mark `{array, slice}::{from_ref, from_mut}` as const fn)
- #90221 (Fix ICE when forgetting to `Box` a parameter to a `Self::func` call)
- #90234 (Temporarily turn overflow checks off for rustc-rayon-core)
Matthias Krüger [Sun, 24 Oct 2021 13:48:46 +0000 (15:48 +0200)]
Rollup merge of #90234 - rusticstuff:rustc-rayon-core-no-overflow-checks, r=Mark-Simulacrum
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.
Note that `from_ref` methods require `const_raw_ptr_deref` feature (which seems totally fine, since it's being stabilized, see #89551), `from_mut` methods require `const_mut_refs` (which seems fine too since this PR marks `from_mut` functions as const unstable).
Matthias Krüger [Sun, 24 Oct 2021 13:48:44 +0000 (15:48 +0200)]
Rollup merge of #90155 - jsha:outdent-methods, r=GuillaumeGomez,camelid
Fix alignment of method headings for scannability
We sometimes use indentation to indicate something is a heading: The section that comes after is indented by 24px relative to the heading. However, the relationship between the "Implementations" section heading, the `impl` headings it contains, and the `pub fn` subheadings within each impl, is awkward. It goes **Implementations**, 15px indent, `impl`, 5px indent, `pub fn`, 4px indent, docblock.
I line up `impl` and `pub fn` with the `Implementations` heading, give `impl` a larger font size to indicate it is higher in the hierarchy, and indent the docblock a full 24px relative to their parent, matching the indents we use elsewhere to distinguish section headings. By letting the `pub fn` stick out to the left of the docblock, I think this makes methods significantly more scannable.
Matthias Krüger [Sun, 24 Oct 2021 13:48:43 +0000 (15:48 +0200)]
Rollup merge of #90100 - Mark-Simulacrum:speed-macos-ci, r=pietroalbini
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).
bors [Sun, 24 Oct 2021 06:29:41 +0000 (06:29 +0000)]
Auto merge of #90208 - Mark-Simulacrum:hash-bytes-fast, r=oli-obk
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.
bors [Sat, 23 Oct 2021 20:59:29 +0000 (20:59 +0000)]
Auto merge of #90175 - cuviper:min-llvm-12, r=nagisa
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.
Mark Rousskov [Sat, 23 Oct 2021 16:11:05 +0000 (12:11 -0400)]
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.
This should hopefully be an improvement for that code.
bors [Sat, 23 Oct 2021 15:53:50 +0000 (15:53 +0000)]
Auto merge of #90203 - matthiaskrgr:rollup-v215wew, r=matthiaskrgr
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)
Matthias Krüger [Sat, 23 Oct 2021 12:58:42 +0000 (14:58 +0200)]
Rollup merge of #90168 - tmiasko:const-qualif-storage, r=matthewjasper
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.
Matthias Krüger [Sat, 23 Oct 2021 12:58:41 +0000 (14:58 +0200)]
Rollup merge of #89829 - voidc:assoc-const-variance, r=lcnr
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.
Matthias Krüger [Sat, 23 Oct 2021 12:58:40 +0000 (14:58 +0200)]
Rollup merge of #88041 - Aaron1011:deny-proc-macro-hack, r=wesleywiser
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.
bors [Sat, 23 Oct 2021 12:51:15 +0000 (12:51 +0000)]
Auto merge of #90104 - spastorino:coherence-for-negative-trait, r=nikomatsakis
Implement coherence checks for negative trait impls
The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3).
This feature is necessary to handle the following from impl on box.
```rust
impl From<&str> for Box<dyn Error> { ... }
```
Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future, and thus prevents the `From` impl in `alloc` that would cause overlap with `From<E: Error> for Box<dyn Error>`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error`, making the `From` impl compile.
We would have this in `alloc`:
```rust
impl From<&str> for Box<dyn Error> {} // A
impl<E> From<E> for Box<dyn Error> where E: Error {} // B
```
and this in `core`:
```rust
trait Error {}
impl !Error for &str {}
```
r? `@nikomatsakis`
This PR was built on top of `@yaahc` PR #85764.
Language team proposal: to https://github.com/rust-lang/lang-team/issues/96
bors [Sat, 23 Oct 2021 09:21:45 +0000 (09:21 +0000)]
Auto merge of #90065 - cjgillot:novalcache, r=Mark-Simulacrum
Do not depend on the stored value when trying to cache on disk.
Having different criteria for loading and saving of query results can lead to saved results that may never be loaded.
Since the on-disk cache is discarded as soon as a compilation error is issued, there should not be any need for an exclusion mecanism based on errors.
As a result, the possibility to condition the storage on the value itself does not appear useful.
Tomasz Miąsko [Fri, 22 Oct 2021 00:00:00 +0000 (00:00 +0000)]
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.
Matthias Krüger [Sat, 23 Oct 2021 03:28:27 +0000 (05:28 +0200)]
Rollup merge of #90122 - rusticstuff:ci_curl_max_time, r=Mark-Simulacrum
CI: make docker cache download and `docker load` time out after 10 minutes
Might help to prevent timeouts we have been seeing:
* https://github.com/rust-lang-ci/rust/runs/3946294286?check_suite_focus=true#step:25:23
* https://github.com/rust-lang-ci/rust/runs/3956799200?check_suite_focus=true#step:25:22
* https://github.com/rust-lang-ci/rust/runs/3962928502?check_suite_focus=true#step:25:23
* https://github.com/rust-lang-ci/rust/runs/3967892291?check_suite_focus=true
* https://github.com/rust-lang-ci/rust/runs/3971202204?check_suite_focus=true
If the download or loading the images into docker times out the CI will still continue and rebuild the docker image from scratch.
Matthias Krüger [Sat, 23 Oct 2021 03:28:26 +0000 (05:28 +0200)]
Rollup merge of #90117 - calebsander:fix/rsplit-clone, r=yaahc
Make RSplit<T, P>: Clone not require T: Clone
This addresses a TODO comment. The behavior of `#[derive(Clone)]` *does* result in a `T: Clone` requirement. Playground example:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a8b1a9581ff8893baf401d624a53d35b
Add a manual `Clone` implementation, mirroring `Split` and `SplitInclusive`.
`(R)?SplitN(Mut)?` don't have any `Clone` implementations, but I'll leave that for its own pull request.
Matthias Krüger [Sat, 23 Oct 2021 03:28:25 +0000 (05:28 +0200)]
Rollup merge of #90087 - calebcartwright:rustfmt-subtree, r=calebcartwright
Sync rustfmt subtree
There's a large number of small fixes and new features, but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20
Matthias Krüger [Sat, 23 Oct 2021 03:28:24 +0000 (05:28 +0200)]
Rollup merge of #90070 - llogiq:compiletest-config-edition, r=Mark-Simulacrum
Add edition configuration to compiletest
This allows the compiletest configuration to set a default edition that can still be overridden with header annotations. Doing this will make it far easier for clippy to get our tests to the newest edition.
Matthias Krüger [Sat, 23 Oct 2021 03:28:23 +0000 (05:28 +0200)]
Rollup merge of #89920 - hudson-ayers:location-detail-control, r=davidtwco
Implement -Z location-detail flag
This PR implements the `-Z location-detail` flag as described in https://github.com/rust-lang/rfcs/pull/2091 .
`-Z location-detail=val` controls what location details are tracked when using `caller_location`. This allows users to control what location details are printed as part of panic messages, by allowing them to exclude any combination of filenames, line numbers, and column numbers. This option is intended to provide users with a way to mitigate the size impact of `#[track_caller]`.
Some measurements of the savings of this approach on an embedded binary can be found here: https://github.com/rust-lang/rust/issues/70579#issuecomment-942556822 .
Closes #70580 (unless people want to leave that open as a place for discussion of further improvements).
This is my first real PR to rust, so any help correcting mistakes / understanding side effects / improving my tests is appreciated :)
I have one question: RFC 2091 specified this as a debugging option (I think that is what -Z implies?). Does that mean this can never be stabilized without a separate MCP? If so, do I need to submit an MCP now, or is the initial RFC specifying this option sufficient for this to be merged as is, and then an MCP would be needed for eventual stabilization?
Matthias Krüger [Sat, 23 Oct 2021 03:28:22 +0000 (05:28 +0200)]
Rollup merge of #89468 - FabianWolff:issue-89358, r=jackh726
Report fatal lexer errors in `--cfg` command line arguments
Fixes #89358. The erroneous behavior was apparently introduced by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/commit/a678e3191197f145451c97c6cc884e15cae38186; the idea is to silence individual parser errors and instead emit one catch-all error message after parsing. However, for the example in #89358, a fatal lexer error is created here:
https://github.com/rust-lang/rust/blob/edebf77e0090195bf80c0d8cda821e1bf9d03053/compiler/rustc_parse/src/lexer/mod.rs#L340-L349
This fatal error aborts the compilation, and so the call to `new_parser_from_source_str()` never returns and the catch-all error message is never emitted. I have therefore changed the `SilentEmitter` to silence only non-fatal errors; with my changes, for the rustc invocation described in #89358:
```sh
rustc --cfg "abc\""
```
I get the following output:
```
error[E0765]: unterminated double quote string
|
= note: this error occurred on the command line: `--cfg=abc"`
```
Matthias Krüger [Sat, 23 Oct 2021 03:28:19 +0000 (05:28 +0200)]
Rollup merge of #83233 - jethrogb:split_array, r=yaahc
Implement split_array and split_array_mut
This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to #74373, #75026, etc. Fixes #74674.
This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
bors [Sat, 23 Oct 2021 03:06:21 +0000 (03:06 +0000)]
Auto merge of #90054 - michaelwoerister:v0-mangling-in-compiler, r=Mark-Simulacrum
Make new symbol mangling scheme default for compiler itself.
As suggest in https://github.com/rust-lang/rust/pull/89917#issuecomment-945888574, this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).
Looks like this if `CStr::from_ptr` is allowed to be inlined.
```asm
before:
push rax
call qword ptr [rip + std::ffi::c_str::CStr::from_ptr@GOTPCREL]
mov rcx, rax
cmp rdx, 1
sete dl
test rax, rax
sete al
or al, dl
jne .LBB1_2
mov dl, byte ptr [rcx]
.LBB1_2:
xor al, 1
pop rcx
ret
after:
mov dl, byte ptr [rdi]
test dl, dl
setne al
ret
```
Note that optimization turned this from O(N) to O(1) in terms of performance, as LLVM knows that it doesn't really need to call `strlen` to determine whether a string is empty or not.
Assemple trait alias candidates for negative polarity
This doesn't work properly yet, we would probably need to implement an
`assembly_neg_candidates` and consider things like `T: !AB` as `T: !A`
|| `T: !B`
bors [Fri, 22 Oct 2021 14:25:23 +0000 (14:25 +0000)]
Auto merge of #90161 - JohnTitor:rollup-1j2qc8m, r=JohnTitor
Rollup of 14 pull requests
Successful merges:
- #87537 (Clarify undefined behaviour in binary heap, btree and hashset docs)
- #88624 (Stabilize feature `saturating_div` for rust 1.58.0)
- #89257 (Give better error for `macro_rules name`)
- #89665 (Ensure that pushing empty path works as before on verbatim paths)
- #89895 (Don't mark for loop iter expression as desugared)
- #89922 (Update E0637 description to mention `&` w/o an explicit lifetime name)
- #89944 (Change `Duration::[try_]from_secs_{f32, f64}` underflow error)
- #89991 (rustc_ast: Turn `MutVisitor::token_visiting_enabled` into a constant)
- #90028 (Reject closures in patterns)
- #90069 (Fix const qualification when executed after promotion)
- #90078 (Add a regression test for issue-83479)
- #90114 (Add some tests for const_generics_defaults)
- #90115 (Add test for issue #78561)
- #90129 (triagebot: Treat `I-*nominated` like `I-nominated`)
Yuki Okushi [Fri, 22 Oct 2021 10:42:51 +0000 (19:42 +0900)]
Rollup merge of #90114 - BoxyUwU:cg_defaults_tests, r=lcnr
Add some tests for const_generics_defaults
I think this covers some of the stuff required for stabilisation report, some of these tests are probably covering stuff we already have but it can't hurt to have more :)
Yuki Okushi [Fri, 22 Oct 2021 10:42:50 +0000 (19:42 +0900)]
Rollup merge of #90078 - JohnTitor:test-83479, r=Mark-Simulacrum
Add a regression test for issue-83479
Add a regression test for https://github.com/rust-lang/rust/issues/83479#issue-841147340, but not close the issue, see https://github.com/rust-lang/rust/issues/83479#issuecomment-947255641.
Yuki Okushi [Fri, 22 Oct 2021 10:42:49 +0000 (19:42 +0900)]
Rollup merge of #90069 - tmiasko:promoted-const-qualif, r=oli-obk
Fix const qualification when executed after promotion
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
Yuki Okushi [Fri, 22 Oct 2021 10:42:46 +0000 (19:42 +0900)]
Rollup merge of #89922 - JohnTitor:update-e0637, r=jackh726
Update E0637 description to mention `&` w/o an explicit lifetime name
Deal with https://github.com/rust-lang/rust/issues/89824#issuecomment-941598647. Another solution would be splitting the error code into two as (I think) it's a bit unclear to users why they have the same error code.
Yuki Okushi [Fri, 22 Oct 2021 10:42:45 +0000 (19:42 +0900)]
Rollup merge of #89895 - camsteffen:for-loop-head-span, r=davidtwco
Don't mark for loop iter expression as desugared
We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
Yuki Okushi [Fri, 22 Oct 2021 10:42:42 +0000 (19:42 +0900)]
Rollup merge of #88624 - kellerkindt:master, r=JohnTitor
Stabilize feature `saturating_div` for rust 1.58.0
The tracking issue is #89381
This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](https://github.com/rust-lang/rust/pull/87921#issuecomment-899357720) and [here](https://github.com/rust-lang/rust/pull/87921#discussion_r691888556). It extends the list of saturating operations on integer types (like `saturating_add`, `saturating_sub`, `saturating_mul`, ...) by the function `fn saturating_div(self, rhs: Self) -> Self`.
The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first.
Yuki Okushi [Fri, 22 Oct 2021 10:42:41 +0000 (19:42 +0900)]
Rollup merge of #87537 - Wilfred:improve-min-heap-docs, r=Mark-Simulacrum
Clarify undefined behaviour in binary heap, btree and hashset docs
Previously, it wasn't clear whether "This could include" was referring to logic errors, or undefined behaviour. Tweak wording to clarify this sentence does not relate to UB.