Yet more `parse_tt` improvements
Including lots of comment improvements, and an overhaul of how `matches` work that gives big speedups.
r? `@petrochenkov`
Contrary to popular belief, `codegen_fulfill_obligation` does not get used solely in codegen, so we cannot rely on `param_env` being set to RevealAll and thus revealing the hidden types instead of constraining them.
allow arbitrary inherent impls for builtin types in core
Part of https://github.com/rust-lang/compiler-team/issues/487. Slightly adjusted after some talks with `@m-ou-se` about the requirements of `t-libs-api`.
This adds a crate attribute `#![rustc_coherence_is_core]` which allows arbitrary impls for builtin types in core.
For other library crates impls for builtin types should be avoided if possible. We do have to allow the existing stable impls however. To prevent us from accidentally adding more of these in the future, there is a second attribute `#[rustc_allow_incoherent_impl]` which has to be added to **all impl items**. This only supports impls for builtin types but can easily be extended to additional types in a future PR.
This implementation does not check for overlaps in these impls. Perfectly checking that requires us to check the coherence of these incoherent impls in every crate, as two distinct dependencies may add overlapping methods. It should be easy enough to detect if it goes wrong and the attribute is only intended for use inside of std.
The first two commits are mostly unrelated cleanups.
Strict Provenance MVP
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
See #95228
Rollup of 5 pull requests
Successful merges:
- #95294 (Document Linux kernel handoff in std::io::copy and std::fs::copy)
- #95443 (Clarify how `src/tools/x` searches for python)
- #95452 (fix since field version for termination stabilization)
- #95460 (Spellchecking compiler code)
- #95461 (Spellchecking some comments)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Lazy type-alias-impl-trait take two
### user visible change 1: RPIT inference from recursive call sites
Lazy TAIT has an insta-stable change. The following snippet now compiles, because opaque types can now have their hidden type set from wherever the opaque type is mentioned.
```rust
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return 42
}
let x: u32 = bar(false); // this errors on stable
99
}
```
The return type of `bar` stays opaque, you can't do `bar(false) + 42`, you need to actually mention the hidden type.
### user visible change 2: divergence between RPIT and TAIT in return statements
Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So
```rust
#![feature(type_alias_impl_trait)]
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
return vec![42];
}
std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator
}
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return vec![42]
}
std::iter::empty().collect() // Works, magic (accidentally stabilized, not intended)
}
```
But when we are working with the return value of a recursive call, the behavior of RPIT and TAIT is the same:
```rust
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
return vec![];
}
let mut x = foo(false);
x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator
vec![]
}
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return vec![];
}
let mut x = bar(false);
x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator
vec![]
}
```
### user visible change 3: TAIT does not merge types across branches
In contrast to RPIT, TAIT does not merge types across branches, so the following does not compile.
```rust
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
vec![42_i32]
} else {
std::iter::empty().collect()
//~^ ERROR `Foo` cannot be built from an iterator over elements of type `_`
}
}
```
It is easy to support, but we should make an explicit decision to include the additional complexity in the implementation (it's not much, see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this).
### PR formalities
previous attempt: #92007
This PR also includes #92306 and #93783, as they were reverted along with #92007 in #93893fixes#93411fixes#88236fixes#89312fixes#87340fixes#86800fixes#86719fixes#84073fixes#83919fixes#82139fixes#77987fixes#74282fixes#67830fixes#62742fixes#54895
Currently, matches within a sequence are recorded in a new empty
`matches` vector. Then when the sequence finishes the matches are merged
into the `matches` vector of the parent.
This commit changes things so that a sequence mp inherits the matches
made so far. This means that additional matches from the sequence don't
need to be merged into the parent. `push_match` becomes more
complicated, and the current sequence depth needs to be tracked. But
it's a sizeable performance win because it avoids one or more
`push_match` calls on every iteration of a sequence.
The commit also removes `match_hi`, which is no longer necessary.
Suggest wrapping patterns in enum variants
Structured suggestion to wrap a pattern in a single-field enum or struct:
```diff
struct A;
enum B {
A(A),
}
fn main(b: B) {
match b {
- A => {}
+ B::A(A) => {}
}
}
```
Half of #94942, the other half I'm not exactly sure how to fix.
Also includes two drive-by changes (that I am open to splitting out into another PR, but thought they could be rolled up into this one):
- 07776c111f: Makes sure not to suggest wrapping if it doesn't have tuple field constructor (i.e. has named fields)
- 8f2bbb18fd53e5008bb488302dbd354577698ede: Also suggest wrapping expressions in a tuple struct (not just enum variants)
This allows to compute the `BodyOwnerKind` from `DefKind` only, and
removes a direct dependency of some MIR queries onto HIR.
As a side effect, it also simplifies metadata, since we don't need 4
flavours of `EntryKind::*Static` any more.
These debug assertions are all implemented only at runtime using
`const_eval_select`, and in the error path they execute
`intrinsics::abort` instead of being a normal debug assertion to
minimize the impact of these assertions on code size, when enabled.
Of all these changes, the bounds checks for unchecked indexing are
expected to be most impactful (case in point, they found a problem in
rustc).
Fix yet another Box<T, A> ICE
Fixes#95036.
This widens the special case from #94414 to make sure that boxes with a custom allocator are never directly dereferenced.
parallel_compiler: hide dependencies behind feature
Separate dependencies for `parallel_compiler` feature, so they will not be compiled if feature not selected, reducing number of compiled crates from 238 to 224.
Ignore doc comments in a declarative macro matcher.
Fixes#95267. Reverts to the old behaviour before #95159 introduced a
regression.
r? `@petrochenkov`
resolve: Simplify some diagnostic code to avoid an ICE
No need to resolve those paths, they are already resolved, we just need to take the results from `partial_res_map`.
Fixes https://github.com/rust-lang/rust/issues/95327
Tell users that `||` operators are not currently supported in let chain expressions
Tells that `||` operators are not currently supported instead of not allowed. See https://github.com/rust-lang/rust/issues/53667#issuecomment-1066075876
In other words, this PR is pretty much trivial.
Remove `Nonterminal::NtTT`.
It's only needed for macro expansion, not as a general element in the
AST. This commit removes it, adds `NtOrTt` for the parser and macro
expansion cases, and renames the variants in `NamedMatch` to better
match the new type.
r? `@petrochenkov`
Make fatal DiagnosticBuilder yield `!`
Fatal errors should really be fatal, so emitting them should cause us to exit at the same time.
Fine with just throwing away these changes if they're not worthwhile. Also, maybe we want to use an uninhabited enum instead of `!`.
r? `@eddyb` who has been working on `DiagnosticBuilder` stuff, feel free to reassign.
Skip needless bitset for debuginfo
Found this while digging around looking at the inlining logic.
Seemed obvious enough so I decided to try to take care of it.
Is this what you had in mind, `@eddyb?`
It's only needed for macro expansion, not as a general element in the
AST. This commit removes it, adds `NtOrTt` for the parser and macro
expansion cases, and renames the variants in `NamedMatch` to better
match the new type.
Provide suggestion for missing `>` in a type parameter list
When encountering an inproperly terminated type parameter list, provide
a suggestion to close it after the last non-constraint type parameter
that was successfully parsed.
Fix#94058.
Rollup of 5 pull requests
Successful merges:
- #91981 (Recover suggestions and useful information lost in previous PR)
- #93469 (Skip pointing out ambiguous impls in alloc/std crates too in inference errors)
- #95335 (Move resolve_path to rustc_builtin_macros and make it private)
- #95340 (interpret: with enforce_number_validity, ensure integers are truly Scalar::Int (i.e., no pointers))
- #95341 (ARMv6K Horizon OS has_thread_local support)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
ARMv6K Horizon OS has_thread_local support
cc. ```@ian-h-chamberlain```
cc. ```@AzureMarker```
Being an ARM target, it has always had built-in support for `#[thread_local]`. This PR comes in just now because we were testing `std::thread` support with `thread_local_dtor`s. This will hopefully be the last PR for the target specification, unless anymore features will be needed as time goes on.
interpret: with enforce_number_validity, ensure integers are truly Scalar::Int (i.e., no pointers)
This is required for https://github.com/rust-lang/miri/pull/2040
r? ```@oli-obk```
Skip pointing out ambiguous impls in alloc/std crates too in inference errors
This generalizes the logic in `annotate_source_of_ambiguity` to skip printing ambiguity errors traits in `alloc` and `std` as well, not just `core`.
While this does spot-fix the issue mentioned below, it would be nicer to generalize this logic, for example to detect when the trait predicate's `self_ty` has any numerical inference variables. Is it worthwhile to scrap this solution for one like that?
Fixes#93450
r? `@estebank`
feel free to reassign
When encountering an inproperly terminated type parameter list, provide
a suggestion to close it after the last non-constraint type parameter
that was successfully parsed.
Fix#94058.
Remove `Session::one_time_diagnostic`
This is untracked mutable state, which modified the behaviour of queries.
It was used for 2 things: some full-blown errors, but mostly for lint declaration notes ("the lint level is defined here" notes).
It is replaced by the diagnostic deduplication infra which already exists in the diagnostic emitter.
A new diagnostic level `OnceNote` is introduced specifically for lint notes, to deduplicate subdiagnostics.
As a drive-by, diagnostic emission takes a `&mut` to allow dropping the `SubDiagnostic`s.
incr. comp.: Let compiler retry finalizing session directory a few times.
In my local testing this fixed issue https://github.com/rust-lang/rust/issues/86929. I wasn't able to come up with a regression test for it though.
Swap DtorckConstraint to DropckConstraint
This change was made as per suspicion that this struct was never renamed after consistent use of DropCk.
This also clarifies the meaning behind the name of this structure.
Fixes https://github.com/rust-lang/rust/issues/94310
resolve: Do not build expensive suggestions if they are not actually used
And remove a bunch of (conditionally) unused parameters from path resolution functions.
This helps with performance issues in https://github.com/rust-lang/rust/pull/94857, and should be helpful in general even without that.
Currently it copies a `KleeneOp` and a `Token` out of a
`SequenceRepetition`. It's better to store a reference to the
`SequenceRepetition`, which is now possible due to #95159 having changed
the lifetimes.
The `Lrc` is only relevant within `transcribe()`. There, the `Lrc` is
helpful for the non-`NtTT` cases, because the entire nonterminal is
cloned. But for the `NtTT` cases the inner token tree is cloned (a full
clone) and so the `Lrc` is of no help.
This commit splits the `NtTT` and non-`NtTT` cases, avoiding the useless
`Lrc` in the former case, for the following effect on macro-heavy
crates.
- It reduces the total number of allocations a lot.
- It increases the size of some of the remaining allocations.
- It doesn't affect *peak* memory usage, because the larger allocations
are short-lived.
This overall gives a speed win.
add diagnostic items for clippy's `trim_split_whitespace`
Adding the following diagnostic items:
* str_split_whitespace,
* str_trim,
* str_trim_start,
* str_trim_end
They are needed for https://github.com/rust-lang/rust-clippy/pull/8575
r? `@flip1995`
debuginfo: Fix debuginfo for Box<T> where T is unsized.
Before this fix, the debuginfo for the fields was generated from the struct defintion of Box<T>, but (at least at the moment) the compiler pretends that Box<T> is just a (fat) pointer, so the fields need to be `pointer` and `vtable` instead of `__0: Unique<T>` and `__1: Allocator`.
This is meant as a temporary mitigation until we can make sure that simply treating Box as a regular struct in debuginfo does not cause too much breakage in the ecosystem.
r? ````@wesleywiser````
Clarify which kinds of MIR are allowed during which phases.
This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked.
There was also some disagreement between the `MirPhase` docs and validator as to what it meant for the `body.phase` field to have a certain value. This PR resolves those disagreements in favor of the `MirPhase` docs (which is what the pass manager implemented), adjusting the validator accordingly. The result is now that the `DropLowering` phase begins with the end of the elaborate drops pass, and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me, but as long as it's documented accurately it should be ok.
r? rust-lang/mir-opt
Also remove a redundant parameter from `fn resolve_path(_with_ribs)`, `crate_lint: CrateLint` is a more detailed version of `record_used: bool` with `CrateLint::No` meaning `false` and anything else meaning `true`.
Separate const prop lints from optimizations
r? `@oli-obk`
Separates lints and optimizations during const prop by moving the lints into their own file and checking them during post borrowck cleanup.
Thanks to `@oli-obk` for mentoring me.
This change was made as per suspicion that this struct was never renamed after consistent use of DropCk.
This also clarifies the meaning behind the name of this structure.
Change Thir to lazily create constants
To allow `AbstractConst`s to work with the previous thir changes we made and those we want to make, i.e. to avoid problems due to `ValTree` and `ConstValue` conversions, we instead switch to a thir representation for constants that allows us to lazily create constants.
r? `@oli-obk`
Properly track `ImplObligations`
Instead of probing for all possible `impl`s that could have caused an
`ImplObligation`, keep track of its `DefId` and obligation spans for
accurate error reporting.
Follow to #89580. Addresses #89418.
Before this fix, the debuginfo for the fields was generated from the
struct defintion of Box<T>, but (at least at the moment) the compiler
pretends that Box<T> is just a (fat) pointer, so the fields need to be
`pointer` and `vtable` instead of `__0: Unique<T>` and `__1: Allocator`.
This is meant as a temporary mitigation until we can make sure that
simply treating Box as a regular struct in debuginfo does not cause too
much breakage in the ecosystem.
`run-rustfix` applies all suggestions regardless of their Applicability.
There's a flag, `rustfix-only-machine-applicable`, that does what it
says, but then the produced `.fixed` file would have invalid code from
the suggestions that weren't applied. So, I moved the cases of postfix
increment, in which case multiple suggestions are given, to the
`-notfixed` test, which does not run rustfix.
I also changed the Applicability to Unspecified since MaybeIncorrect
requires that the code be valid, even if it's incorrect.
Instead of probing for all possible impls that could have caused an
`ImplObligation`, keep track of its `DefId` and obligation spans for
accurate error reporting.
Follow up to #89580. Addresses #89418.
Remove some unnecessary clones.
Tweak output for auto trait impl obligations.
This enhances documentation with these details and extends the validator to check these requirements
more thoroughly. As a part of this, we add a new `Deaggregated` phase, and rename other phases so
that their names more naturally correspond to what they represent.
interpret/memory: simplify check_and_deref_ptr
*Finally* I saw a way to make this code simpler. The odd preprocessing in `let ptr_or_addr =` has bothered me since forever, but it actually became unnecessary in the last provenance refactoring. :)
This also leads to slightly more explicit error messages as a nice side-effect. 🎉
r? `@oli-obk`
Better errors when a Copy impl on a Struct is not self-consistent
As discovered in a Zulip thread with `@nnethercote` and `@Mark-Simulacrum,` it's not immediately obvious why a field on an ADT doesn't implement `Copy`. This PR attempts to give slightly more detailed information by spinning up a fulfillment context to try to dig down and discover transitive fulfillment errors that cause `is_copy_modulo_regions` to fail on a ADT field.
The error message still kinda sucks, but should only show up in the case that an existing error message was totally missing... so I think it's a good compromise for now?
diagnostics: do not suggest `fn foo({ <body> }`
Instead of suggesting that the body always replace the last character on the line, presuming it must be a semicolon, the parser should instead check what the last character is, and append the body if it is anything else.
Fixes#83104
Rename `~const Drop` to `~const Destruct`
r? `@oli-obk`
Completely switching to `~const Destructible` would be rather complicated, so it seems best to add it for now and wait for it to be backported to beta in the next release.
The rationale is to prevent complications such as #92149 and #94803 by introducing an entirely new trait. And `~const Destructible` reads a bit better than `~const Drop`. Name Bikesheddable.
interpret/validity: improve clarity
I was confused by my own (ancient) comment in `validity.rs` so I figured I'd clarify. (And I don't think ZST-ness is relevant at all inside that branch, no idea where that comment comes from.)
Also `extend` seems more clear than `clone_from`.
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
I am... pretty sure no one is relying on this.
An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.
- Fixesrust-lang/rust#95002.
- Fixesrust-lang/rust#95064.
- Fixesrust-lang/rust#95122.
Instead of suggesting that the body always replace the last character on the
line, presuming it must be a semicolon, the parser should instead check what
the last character is, and append the body if it is anything else.
Fixes#83104
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
Introduce `TtParser`
These commits make a number of changes to declarative macro expansion, resulting in code that is shorter, simpler, and faster.
Best reviewed one commit at a time.
r? `@petrochenkov`
As its name suggests, `TokenTreeOrTokenTreeSlice` is either a single
`TokenTree` or a slice of them. It has methods `len` and `get_tt` that
let it be treated much like an ordinary slice. The reason it isn't an
ordinary slice is that for `TokenTree::Delimited` the open and close
delimiters are represented implicitly, and when they are needed they are
constructed on the fly with `Delimited::{open,close}_tt`, rather than
being present in memory.
This commit changes `Delimited` so the open and close delimiters are
represented explicitly. As a result, `TokenTreeOrTokenTreeSlice` is no
longer needed and `MatcherPos` and `MatcherTtFrame` can just use an
ordinary slice. `TokenTree::{len,get_tt}` are also removed, because they
were only needed to support `TokenTreeOrTokenTreeSlice`.
The change makes the code shorter and a little bit faster on benchmarks
that use macro expansion heavily, partly because `MatcherPos` is a lot
smaller (less data to `memcpy`) and partly because ordinary slice
operations are faster than `TokenTreeOrTokenTreeSlice::{len,get_tt}`.
Suggest constraining param for unary ops when missing trait impl
This PR adds a suggestion of constraining param for unary ops `-` and `!` when the corresponding trait implementation
is missing.
Fixs #94543.
BTW, this is my first time to touch rustc, please correct me if I did anything wrong.
rename LocalState::Uninitialized to Unallocated
This is to avoid confusion with `Uninit` as in `ScalarMaybeUninit`, which is very different.
r? `@oli-obk`
Inline some parser functions
Some crates that do a lot of complex declarative macro expansion spend a lot of time parsing (and reparsing) tokens. These commits inline some functions for some minor speed wins.
r? `@ghost`
Disable almost certainly unsound early otherwise branch MIR opt
Originally thought this was just an MIR semantics issue, but it's not.
r? rust-lang/mir-opt
The call site within `Parser::bump` is hot.
Also add an inline annotation to `Parser::next_tok`. It was already
being inlined by the compiler; this just makes sure that continues.
Return err instead of ICE
Having `escaping_bound_vars` results in ICE when trying to create `ty::Binder::dummy`, to avoid it we return err like the line above. I think this requires a more sophisticated fix, I would love to investigate if mentorship is available 🤓Fixes#95023 and #85350
suggest removing type ascription in bad parsing position
Not sure how to test this with the non-nightly suggestion. Didn't add a new UI test because it already manifests in an existing UI test.
Fixes#95014
By putting them in `TtParser`, we can reuse them for every rule in a
macro. With that done, they can be `SmallVec` instead of `Vec`, and this
is a performance win because these vectors are hot and `SmallVec`
operations are a bit slower due to always needing an "inline or heap?"
check.
This type was a small performance win for `html5ever`, which uses a
macro with hundreds of very simple rules that don't contain any
metavariables. But this type is complicated (extra lifetimes) and
perf-neutral for macros that do have metavariables.
This commit removes `MatcherPosHandle`, simplifying things a lot. This
increases the allocation rate for `html5ever` and similar cases a bit,
but makes things easier for follow-up changes that will improve
performance more than what we lost here.
Give more details in `Display` for `hir::Target`
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
With this change the error is more actionable
```
error[E0718]: `into_try_type` language item must be applied to a required trait method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a required trait method, not a provided trait method
```
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
Always evaluate all cfg predicate in all() and any()
This pull-request adjust the handling of the `all()` and `any()` to always evaluate every cfg predicate because not doing so result in accepting incorrect `cfg`:
```rust
#[cfg(any(unix, foo::bar))] // Should error on foo::bar, but does not on unix platform (but does on non unix platform)
fn foo1() {}
#[cfg(all(foo, foo::bar))] // Should error on foo::bar, but does not
fn foo2() {}
#[cfg(all(foo::bar, foo))] // Correctly error on foo::bar
fn foo3() {}
#[cfg(any(foo::bar, foo))] // Correctly error on foo::bar
fn foo4() {}
```
This pull-request take the side to directly turn it into a hard error instead of having a future incompatibility lint because the combination to get this incorrect behavior is unusual and highly probable that some code have this without noticing.
A [search](https://cs.github.com/?scopeName=All+repos&scope=&q=lang%3Arust+%2Fany%5C%28%5Ba-zA-Z%5D%2C+%5Ba-zA-Z%5D%2B%3A%3A%5Ba-zA-Z%5D%2B%2F) on Github reveal no such instance nevertheless a Crater run should probably be done before merging this.
This was discover in https://github.com/rust-lang/rust/pull/94175 when trying to lint on the second predicate. Also note that this seems to have being introduce with Rust 1.27.0: https://rust.godbolt.org/z/KnfqKv15f.
r? `@petrochenkov`
It currently has no state, just the three methods `parse_tt`,
`parse_tt_inner`, and `bb_items_ambiguity_error`.
This commit is large but trivial, and mostly consists of changes to the
indentation of those methods. Subsequent commits will do more.
Rollup of 4 pull requests
Successful merges:
- #95013 (Update browser-ui-test version to 0.8.2)
- #95039 (Make negative coherence work when there's impl negative on super predicates)
- #95047 (Refactor: remove an unnecessary pattern for ignoring all parts)
- #95048 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Implement -Z oom=panic
This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596).
Perf and binary size tests show negligible impact.
Rollup of 10 pull requests
Successful merges:
- #91133 (Improve `unsafe` diagnostic)
- #93222 (Make ErrorReported impossible to construct outside `rustc_errors`)
- #93745 (Stabilize ADX target feature)
- #94309 ([generator_interior] Be more precise with scopes of borrowed places)
- #94698 (Remove redundant code from copy-suggestions)
- #94731 (Suggest adding `{ .. }` around a const function call with arguments)
- #94960 (Fix many spelling mistakes)
- #94982 (Add deprecated_safe feature gate and attribute, cc #94978)
- #94997 (debuginfo: Fix ICE when generating name for type that produces a layout error.)
- #95000 (Fixed wrong type name in comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove redundant code from copy-suggestions
Follow up to #94375, just remove some code that is not necessary anymore. This may make the perf of such suggestions a little bit worse, but I don't think this is significant.
r? `@estebank`
[generator_interior] Be more precise with scopes of borrowed places
Previously the generator interior type checking analysis would use the nearest temporary scope as the scope of a borrowed value. This ends up being overly broad for cases such as:
```rust
fn status(_client_status: &Client) -> i16 {
200
}
fn main() {
let client = Client;
let g = move || match status(&client) {
_status => yield,
};
assert_send(g);
}
```
In this case, the borrow `&client` could be considered in scope for the entirety of the `match` expression, meaning it would be viewed as live across the `yield`, therefore making the generator not `Send`.
In most cases, we want to use the enclosing expression as the scope for a borrowed value which will be less than or equal to the nearest temporary scope. This PR changes the analysis to use the enclosing expression as the scope for most borrows, with the exception of borrowed RValues which are true temporary values that should have the temporary scope. There's one further exception where borrows of a copy such as happens in autoref cases also should be ignored despite being RValues.
Joint work with `@nikomatsakis`
Fixes#57017
r? `@tmandry`
Stabilize ADX target feature
This is a continuation of #60109, which noted that while the ADX intrinsics were stabilized, the corresponding target feature never was.
This PR follows the same general structure and stabilizes the ADX target feature.
See also https://github.com/rust-lang/rust/issues/44839 - tracking issue for target feature
Make ErrorReported impossible to construct outside `rustc_errors`
There are a few places were we have to construct it, though, and a few
places that are more invasive to change. To do this, we create a
constructor with a long obvious name.
cc #69426 `@varkor` `@eddyb` `@estebank`
I actually didn't see that I was assigned to this issue until now...
