In #120699 I moved some code dealing with `has_future_breakage` earlier
in `emit_diagnostic`. Issue #126521 identified a case where that
reordering was invalid (leading to an assertion failure) for some `Expect`
diagnostics.
This commit partially undoes the change, by moving the handling of
unstable `Expect` diagnostics earlier again. This makes
`emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes#126521.
Implement `array::repeat`
See rust-lang/libs-team#310.
I've decided to make the function use the input value as last element instead of cloning it to every position and dropping it, and to make this part of the API so that callers are not surprised by this behaviour.
TODO: open a tracking issue. I'll wait for the ACP to be accepted, first.
`@rustbot` label +T-libs-api +T-libs
r? libs
Apparently MIR borrowck cares about at least one of these for checking variance.
In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing.
(Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)
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`
The way it is implemented currently try_force_from_dep_node returns true
as long as there's a function to force the query. It wasn't this way
from the beginning, earlier version was producing forcing result and it
was changed in https://github.com/rust-lang/rust/pull/89978, I couldn't
find any comments addressing this change.
One way it can fail is by failing to recover the query in
DepNodeParams::recover - when we are trying to query something that no
longer exists in the current environment
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
MCDC Coverage: instrument last boolean RHS operands from condition coverage
Fresh PR from #124652
--
This PR ensures that the top-level boolean expressions that are not part of the control flow are correctly instrumented thanks to condition coverage.
See discussion on https://github.com/rust-lang/rust/issues/124120.
Depends on `@Zalathar` 's condition coverage implementation #125756.
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;
|
```
