Tweak parsing recovery of enums, for exprs and match arm patterns
Tweak recovery of `for (pat in expr) {}` for more accurate spans.
When encountering `match` arm `(pat if expr) => {}`, recover and suggest removing parentheses. Fix#100825.
When encountering malformed enums, try more localized per-variant parse recovery.
Move parser recovery tests to subdirectory.
Pass +forced-atomics feature for riscv32{i,im,imc}-unknown-none-elf
As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd
~~This PR is currently marked as a draft because:~~
- ~~`forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153).~~ EDIT: Fixed
- ~~`forced-atomics` target feature has been added in LLVM 16 (f5ed0cb217), but the current minimum LLVM version [is 15](90f0b24ad3/src/bootstrap/llvm.rs (L557)). In LLVM 15, the atomic load/store of these targets generates libcalls anyway.~~ EDIT: LLVM 15 has been dropped
Depending on the policy on the minimum LLVM version for these targets, this may be blocked until the minimum LLVM version is increased to 16.
r? `@Amanieu`
ConstProp: Correctly remove const if unknown value assigned to it.
Closes#118328
The problematic sequence of MIR is:
```rust
_1 = const 0_usize;
_1 = const _; // This is an associated constant we can't know before monomorphization.
_0 = _1;
```
1. When `ConstProp::visit_assign` happens on `_1 = const 0_usize;`, it records that `0x0usize` is the value for `_1`.
2. Next `visit_assign` happens on `_1 = const _;`. Because the rvalue `.has_param()`, it can't be const evaled.
3. Finaly, `visit_assign` happens on `_0 = _1;`. Here it would think the value of `_1` was `0x0usize` from step 1.
The solution is to remove consts when checking the RValue fails, as they may have contained values that should now be invalidated, as that local was overwritten.
This should probably be back-ported to beta. Stable is more iffy, as it's gone unidentified since 1.70, so I only think it's worthwhile if there's another reason for a 1.74.1 release anyway.
Suggest `let` or `==` on typo'd let-chain
When encountering a bare assignment in a let-chain, suggest turning the
assignment into a `let` expression or an equality check.
```
error: expected expression, found `let` statement
--> $DIR/bad-if-let-suggestion.rs:5:8
|
LL | if let x = 1 && i = 2 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
help: you might have meant to continue the let-chain
|
LL | if let x = 1 && let i = 2 {}
| +++
help: you might have meant to compare for equality
|
LL | if let x = 1 && i == 2 {}
| +
```
Add `never_patterns` feature gate
This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment.
`@scottmcm` has agreed to be my lang-team liaison for this experiment.
Rollup of 7 pull requests
Successful merges:
- #118342 (Dont suggest `!` for path in function call if it has generic args)
- #118383 (Address unused tuple struct fields in the standard library)
- #118401 (`rustc_ast_lowering` cleanups)
- #118409 (format_foreign.rs: unwrap return Option value for `fn position`, as it always returns Some)
- #118413 (Fix the issue of suggesting unwrap/expect for shorthand field)
- #118425 (Update cargo)
- #118429 (Fix a typo in a `format_args!` note)
r? `@ghost`
`@rustbot` modify labels: rollup
format_foreign.rs: unwrap return Option value for `fn position`, as it always returns Some
Trivial cleanup.
It will be nice to have way to run exhaustiveness analysis on similar cases to see dead code.
Fix coroutine validation for mixed panic strategy
Validation introduced in #113124 allows `UnwindAction::Continue` and `TerminatorKind::Resume` to occur only in functions with ABI that can unwind. The function ABI depends on the panic strategy, which can vary across crates.
Usually MIR is built and validated in the same crate. The coroutine drop glue thus far was an exception. As a result validation could fail when mixing different panic strategies.
Avoid the problem by executing `AbortUnwindingCalls` along with the validation.
Fixes#116953.
Eagerly return `ExprKind::Err` on `yield`/`await` in wrong coroutine context
This PR does 2 things:
1. Refuses to lower `.await` or `yield` when we are outside of the right coroutine context for the operator. Instead, we lower to `hir::ExprKind::Err`, to silence subsequent redundant errors.
2. Reworks a bit of the span tracking in `LoweringContext` to fix a bad span when we have something like `let x = [0; async_fn().await]` where the `await` is inside of an anon const. The span for the "item" still kinda sucks, since it overlaps with the `await` span, but at least it's accurate.
Remove HIR opkinds
`hir::BinOp`, `hir::BinOpKind`, and `hir::UnOp` are identical to `ast::BinOp`, `ast::BinOpKind`, and `ast::UnOp`, respectively. This seems silly, so this PR removes the HIR ones. (A re-export lets the AST ones be referred to using a `hir::` qualifier, which avoids renaming churn.)
r? `@cjgillot`
Unify `TraitRefs` and `PolyTraitRefs` in `ValuePairs`
I did this recently with `FnSigs` and `PolyFnSigs` but didn't think to do it with `TraitRefs` and `PolyTraitRefs`.
Cut code size for feature hashing
This locally cuts ~32 kB of .text instructions.
This isn't really a clear win in terms of readability. IMO the code size benefits are worth it (even if they're not necessarily present in the x86_64 hyperoptimized build, I expect them to translate similarly to other platforms). Ultimately there's lots of "small ish" low hanging fruit like this that I'm seeing that seems worth tackling to me, and could translate into larger wins in aggregate.
Rollup of 6 pull requests
Successful merges:
- #118193 (Add missing period in `std::process::Command` docs)
- #118222 (unify read_to_end and io::copy impls for reading into a Vec)
- #118323 (give dev-friendly error message for incorrect config profiles)
- #118378 (Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto)
- #118399 (Clean dead codes in miri)
- #118410 (update test for new LLVM 18 codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
Validation introduced in #113124 allows UnwindAction::Continue and
TerminatorKind::Resume to occur only in functions with ABI that can
unwind. The function ABI depends on the panic strategy, which can vary
across crates.
Usually MIR is built and validated in the same crate. The coroutine drop
glue thus far was an exception. As a result validation could fail when
mixing different panic strategies.
Avoid the problem by executing AbortUnwindingCalls along with the
validation.
When encountering a bare assignment in a let-chain, suggest turning the
assignment into a `let` expression or an equality check.
```
error: expected expression, found `let` statement
--> $DIR/bad-if-let-suggestion.rs:5:8
|
LL | if let x = 1 && i = 2 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
help: you might have meant to continue the let-chain
|
LL | if let x = 1 && let i = 2 {}
| +++
help: you might have meant to compare for equality
|
LL | if let x = 1 && i == 2 {}
| +
```
Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto
Fixes (partially) #60059. Technically, `--target wasm32-unknown-unknown -Clinker-plugin-lto` would complete without errors before, but it was not producing optimized code. At least, it may have been but it was probably not the opt-level people intended.
Similarly to #118377, this could benefit from a warning about using an explicit libLTO path with LLD, which will ignore it and use its internal LLVM. Especially given we always use lld on wasm targets. I left the code open to that possibility rather than making it perfectly neat.
effects: Run `enforce_context_effects` for all method calls
So that we also perform checks when overloaded `PartialEq`s are called.
r? `@compiler-errors`
