Fix duplicated attributes on nonterminal expressions
This PR fixes a long-standing bug (#86055) whereby expression attributes can be duplicated when expanded through declarative macros.
First, consider how items are parsed in declarative macros:
```
Items:
- parse_nonterminal
- parse_item(ForceCollect::Yes)
- parse_item_
- attrs = parse_outer_attributes
- parse_item_common(attrs)
- maybe_whole!
- collect_tokens_trailing_token
```
The important thing is that the parsing of outer attributes is outside token collection, so the item's tokens don't include the attributes. This is how it's supposed to be.
Now consider how expression are parsed in declarative macros:
```
Exprs:
- parse_nonterminal
- parse_expr_force_collect
- collect_tokens_no_attrs
- collect_tokens_trailing_token
- parse_expr
- parse_expr_res(None)
- parse_expr_assoc_with
- parse_expr_prefix
- parse_or_use_outer_attributes
- parse_expr_dot_or_call
```
The important thing is that the parsing of outer attributes is inside token collection, so the the expr's tokens do include the attributes, i.e. in `AttributesData::tokens`.
This PR fixes the bug by rearranging expression parsing to that outer attribute parsing happens outside of token collection. This requires a number of small refactorings because expression parsing is somewhat complicated. While doing so the PR makes the code a bit cleaner and simpler, by eliminating `parse_or_use_outer_attributes` and `Option<AttrWrapper>` arguments (in favour of the simpler `parse_outer_attributes` and `AttrWrapper` arguments), and simplifying `LhsExpr`.
r? `@petrochenkov`
Rollup of 6 pull requests
Successful merges:
- #125447 (Allow constraining opaque types during subtyping in the trait system)
- #125766 (MCDC Coverage: instrument last boolean RHS operands from condition coverage)
- #125880 (Remove `src/tools/rust-demangler`)
- #126154 (StorageLive: refresh storage (instead of UB) when local is already live)
- #126572 (override user defined channel when using precompiled rustc)
- #126662 (Unconditionally warn on usage of `wasm32-wasi`)
r? `@ghost`
`@rustbot` modify labels: rollup
Allow constraining opaque types during subtyping in the trait system
Previous attempt: https://github.com/rust-lang/rust/pull/123979
Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.
It now parses outer attributes before collecting tokens. This avoids the
problem where the outer attribute tokens were being stored twice -- for
the attribute tokesn, and also for the expression tokens.
Fixes#86055.
Rollup of 7 pull requests
Successful merges:
- #123782 (Test that opaque types can't have themselves as a hidden type with incompatible lifetimes)
- #124580 (Suggest removing unused tuple fields if they are the last fields)
- #125787 (Migrate `bin-emit-no-symbols` `run-make` test to `rmake`)
- #126553 (match lowering: expand or-candidates mixed with candidates above)
- #126594 (Make async drop code more consistent with regular drop code)
- #126654 (Make pretty printing for `f16` and `f128` consistent)
- #126656 (rustc_type_ir: Omit some struct fields from Debug output)
r? `@ghost`
`@rustbot` modify labels: rollup
match lowering: expand or-candidates mixed with candidates above
This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
(1, true) => 1,
(2, false) => 2,
(1 | 2, true | false) => 3,
(3 | 4, true | false) => 4,
_ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.
We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
(1 | 2, false) => unreachable!(),
(2, _) => unreachable!(),
_ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.
Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).
This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.
r? ``@matthewjasper``
Suggest removing unused tuple fields if they are the last fields
Fixes#124556
We now check if dead/unused fields are the last fields of the tuple and suggest their removal instead of suggesting them to be changed to `()`.
Test that opaque types can't have themselves as a hidden type with incompatible lifetimes
fixes#122876
This PR used to add extra logic to prevent those cases, but after https://github.com/rust-lang/rust/pull/113169 this is implicitly rejected, because such usages are not defining.
improve tip for inaccessible traits
Improve the tips when the candidate method is from an inaccessible trait.
For example:
```rs
mod m {
trait Trait {
fn f() {}
}
impl<T> Trait for T {}
}
fn main() {
struct S;
S::f();
}
```
The difference between before and now is:
```diff
error[E0599]: no function or associated item named `f` found for struct `S` in the current scope
--> ./src/main.rs:88:6
|
LL | struct S;
| -------- function or associated item `f` not found for this struct
LL | S::f();
| ^ function or associated item not found in `S`
|
= help: items from traits can only be used if the trait is implemented and in scope
- help: trait `Trait` which provides `f` is implemented but not in scope; perhaps you want to import it
+ help: trait `crate:Ⓜ️:Trait` which provides `f` is implemented but not reachable
|
- LL + use crate:Ⓜ️:Trait;
|
```
hir_typeck: be more conservative in making "note caller chooses ty param" note
In https://github.com/rust-lang/rust/pull/122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type.
#126547 found that this note was confusing when the found return type *contains* the expected type, e.g.
```rs
fn f<T>(t: &T) -> T {
t
}
```
because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing.
This PR addresses that by not making the note if the found return type contains the expected return type.
r? ``@fmease`` (since you reviewed the original PR)
Fixes https://github.com/rust-lang/rust/issues/126547
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple variants
This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by ````@RalfJung```` in his review of #126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes#126460
r? ````@compiler-errors````
Place tail expression behind terminating scope
This PR implements #123739 so that we can do further experiments in nightly.
A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following.
```rust
match into_async_iter($iter_expr) {
ref mut iter => match unsafe { Pin::unchecked_new(iter) } {
...
}
}
```
delegation: Implement glob delegation
Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.
The implementation is generally based on the design from https://github.com/rust-lang/rfcs/pull/3530#issuecomment-2020869823, but unlike with list delegation in https://github.com/rust-lang/rust/pull/123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.
Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.
Part of https://github.com/rust-lang/rust/issues/118212.
More thorough status-quo tests for `#[coverage(..)]`
In light of the stabilization push at https://github.com/rust-lang/rust/issues/84605#issuecomment-2166514660, I have written some tests to more thoroughly capture the current behaviour of the `#[coverage(..)]` attribute.
These tests aim to capture the *current* behaviour, which is not necessarily the desired behaviour. For example, some of the error message are not great, some things that perhaps ought to cause an error do not, and recursive coverage attributes have not been implemented yet.
`@rustbot` label +A-code-coverage
coverage: Add debugging flag `-Zcoverage-options=no-mir-spans`
When set, this flag skips the code that normally extracts coverage spans from MIR statements and terminators. That sometimes makes it easier to debug branch coverage and MC/DC coverage instrumentation, because the coverage output is less noisy.
For internal debugging only. If future code changes would make it hard to keep supporting this flag, it should be removed at that time.
`@rustbot` label +A-code-coverage
Rollup of 3 pull requests
Successful merges:
- #126568 (mark undetermined if target binding in current ns is not got)
- #126577 (const_refs_to_static test and cleanup)
- #126584 (Do not ICE in privacy when type inference fails.)
r? `@ghost`
`@rustbot` modify labels: rollup
const_refs_to_static test and cleanup
r? ``@RalfJung``
test the existing behaviour of adt_const_params combined with const_refs_to_static.
also remove a dead error variant about consts referring to statics
Consistently use subtyping in method resolution
fixes#126062
An earlier version of this PR modified how we compute variance, but the root cause was an inconsistency between the usage of `eq` and `sub`, where we assumed that the latter passing implies the former will pass.
r? `@compiler-errors`
When set, this flag skips the code that normally extracts coverage spans from
MIR statements and terminators. That sometimes makes it easier to debug branch
coverage and MC/DC coverage, because the coverage output is less noisy.
For internal debugging only. If other code changes would make it hard to keep
supporting this flag, remove it.
Convert a `span_bug` to a `span_delayed_bug`.
PR #121208 converted this from a `span_delayed_bug` to a `span_bug` because nothing in the test suite caused execution to hit this path. But now fuzzing has found a test case that does hit it. So this commit converts it back to `span_delayed_bug` and adds the relevant test.
Fixes#126385.
r? `@lcnr`
Make suggestion to change `Fn` to `FnMut` work with methods as well
Fixes#125325
The issue occurred because the code that emitted the suggestion to change `Fn` to `FnMut` worked only for function calls and not method calls. This PR makes it work with methods as well.
PR #121208 converted this from a `span_delayed_bug` to a `span_bug`
because nothing in the test suite caused execution to hit this path. But
now fuzzing has found a test case that does hit it. So this commit
converts it back to `span_delayed_bug` and adds the relevant test.
Fixes#126385.
Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope
Implements the change to elided lifetime resolution in *associated consts* subject to FCP here: https://github.com/rust-lang/rust/issues/125190#issue-2301532282
Specifically, walk the enclosing lifetime ribs in an associated const, and if we find no other lifetimes, then resolve to `'static`.
Also make it work for traits, but don't lint -- just give a hard error in that case.
Spell out other trait diagnostic
I recently saw somebody confused about the diagnostic thinking it was suggesting to add an `as` cast. This change is longer but I think it's clearer
tests/ui/lint: Move 19 tests to new `non-snake-case` subdir
Mainly so that it is easier to only run all `non_snake_case`-lint-specific tests with:
./x test tests/ui/lint/non-snake-case
But also to reduce the size of the large `tests/ui/lint` directory. And rename some tests to pass tidy, and remove them from `src/tools/tidy/src/issues.txt`.
Check that alias-relate terms are WF if reporting an error in alias-relate
Check that each of the left/right term is WF when deriving a best error obligation for an alias-relate goal. This will make sure that given `<i32 as NotImplemented>::Assoc = ()` will drill down into `i32: NotImplemented` since we currently treat the projection as rigid.
r? lcnr
