Merged
Conversation
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`". ``` error[E0433]: cannot find `nonexistent` in `existent` --> $DIR/custom_attr_multisegment_error.rs:5:13 | LL | #[existent::nonexistent] | ^^^^^^^^^^^ could not find `nonexistent` in `existent` ```
…enkov
Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of rust-lang/rust#126810 and rust-lang/rust#128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
tail calls: fix copying non-scalar arguments to callee Alternative to rust-lang/rust#144933: when invoking a tail call with a non-scalar argument, we need to delay freeing the caller's local variables until after the callee is initialized, so that we can copy things from the caller to the callee. Fixes rust-lang/rust#144820... but as the FIXMEs in the code show, it's not clear to me whether these are the right semantics. r? @WaffleLapkin
Add a note about elided lifetime Fixes rust-lang/rust#65866 r? @estebank
…jgillot compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness" I don't think this MIR pass is required for soundness. The reasons are: * Something like it was not enabled by default before PR rust-lang/rust#107404 which was the precursor to `SingleUseConsts` (see rust-lang/rust#125910 for the switch). * By following the advice from rust-lang/rust#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0. * Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass. * PR CI pass in rust-lang/rust#151426 which stops enabling it by default in non-optimized builds. As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired. Unblocks rust-lang/rust#151426.
Rename dep node "fingerprints" to distinguish key and value hashes In the query system's dependency graph, each node is associated with two *fingerprints*: one that is typically a hash of the query key, and one that is typically a hash of the query's return value when called with that key. Unfortunately, many identifiers and comments fail to clearly distinguish between these two kinds of fingerprint, which have very different roles in dependency tracking. This is a frequent source of confusion. This PR therefore tries to establish a clear distinction between: - **Key fingerprints** that help to uniquely identify a node (along with its `DepKind`), and are typically a hash of the query key - **Value fingerprints** that help to determine whether a node can be marked green (despite having red dependencies), and are typically a hash of the query value There should be no change to compiler behaviour. r? nnethercote (or compiler)
remove the explicit error for old `rental` versions This was converted to a hard error 20 months ago (in rust-lang/rust#125596). This seems like enough time for anyone still using it to notice, so remove the note entirely now. In comparison, the explicit note for the more impactful `time` breakage was already removed after 6 months (rust-lang/rust#129343). Closes rust-lang/rust#73933. Closes rust-lang/rust#83125. r? @petrochenkov
Remove ShallowInitBox. All uses of this were removed by rust-lang/rust#148190 Split from rust-lang/rust#147862 r? @RalfJung
Fix invalid `mut T` suggestion for `&mut T` in missing lifetime error close: rust-lang/rust#150077 When suggesting to return an owned value instead of a borrowed one, the diagnostic was only removing `&` instead of `&mut `, resulting in invalid syntax like `mut T`. This PR fixes the span calculation to properly cover the entire `&mut ` prefix.
Add documentation note about signed overflow direction In rust-lang/rust#151989 (comment) I noticed that signed overflow direction can be determined by returned wrapped value. It is not very obvious (especially, assuming additional `carry: bool` summand), but it is important if we want to add new leading (signed) limb to big integer in this case. Examples for small summands `x, y: i8` with result extension: | x | y | overflow | result as (u8, i8) | | ---- | ---- | -------- | ------------------ | | -1 | -128 | true | (127, -1) | | 0 | -1 | false | (255, -1) | | 2 | 2 | false | (4, 0) | | 127 | 1 | true | (128, 0) | Here is general proof. 1. Set $s=2^{N-1}$ and let's say `iN::carrying_add(x, y, c)` returns `(result, true)` then $$ \mathrm{result}=\begin{cases} x + y + c + 2s,& x + y + c \le -s-1,\\ x+y+c-2s,& x+y+c\ge s. \end{cases} $$ First case is overflowing below `iN::MIN` and we have $$ \mathrm{result}\ge -s-s+0+2s =0;\qquad \mathrm{result}=x + y + c + 2s\le -s-1+2s = s - 1, $$ so we obtain $[0; s-1]$ which is exactly range of non-negative `iN`. Second case is overflowing above `iN::MAX` and $$ \mathrm{result}=x+y+c-2s\ge s-2s =-s;\qquad \mathrm{result}\le s-1 + s-1+1-2s = -1, $$ that is, $[-s,-1]$ which is exactly range of negative `iN`. 2. Now suppose that `iN::borrowing_sub(x,y,b)` returns `(result, true)` then $$ \mathrm{result}=\begin{cases} x - y - b + 2s,& x - y - b \le -s-1,\\ x - y - b - 2s,& x - y - b\ge s. \end{cases} $$ First case is overflowing below `iN::MIN` and we have $$ \mathrm{result}\ge -s-(s-1)-1+2s =0;\qquad \mathrm{result}=x - y - b + 2s\le -s-1+2s = s - 1. $$ Second case is overflowing above `iN::MAX` and $$ \mathrm{result}=x-y-b-2s\ge s-2s =-s;\qquad \mathrm{result}\le s-1 - (-s) - 0 - 2s = -1. $$
Implement opt-bisect-limit for MIR closes: rust-lang/rust#150910 Enable bisecting MIR optimization passes to enhance debuggability. discussions on zulip: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/MIR.20dump.20the.20pass.20names/with/573219207 ### Check it works #### Sample code ```rust fn abs(num: isize) -> usize { if num < 0 { -num as usize } else { num as usize } } fn main() { println!("{}", abs(-10)); } ``` #### Output ```shell rustc +mir -Zmir-opt-bisect-limit=30 src/main.rs BISECT: running pass (1) CheckAlignment on main[89d5]::main BISECT: running pass (2) CheckNull on main[89d5]::main BISECT: running pass (3) CheckEnums on main[89d5]::main BISECT: running pass (4) LowerSliceLenCalls on main[89d5]::main BISECT: running pass (5) InstSimplify-before-inline on main[89d5]::main BISECT: running pass (6) ForceInline on main[89d5]::main BISECT: running pass (7) RemoveStorageMarkers on main[89d5]::main BISECT: running pass (8) RemoveZsts on main[89d5]::main BISECT: running pass (9) RemoveUnneededDrops on main[89d5]::main BISECT: running pass (10) UnreachableEnumBranching on main[89d5]::main BISECT: running pass (11) SimplifyCfg-after-unreachable-enum-branching on main[89d5]::main BISECT: running pass (12) InstSimplify-after-simplifycfg on main[89d5]::main BISECT: running pass (13) SimplifyConstCondition-after-inst-simplify on main[89d5]::main BISECT: running pass (14) SimplifyLocals-before-const-prop on main[89d5]::main BISECT: running pass (15) SimplifyLocals-after-value-numbering on main[89d5]::main BISECT: running pass (16) MatchBranchSimplification on main[89d5]::main BISECT: running pass (17) SingleUseConsts on main[89d5]::main BISECT: running pass (18) SimplifyConstCondition-after-const-prop on main[89d5]::main BISECT: running pass (19) SimplifyConstCondition-final on main[89d5]::main BISECT: running pass (20) RemoveNoopLandingPads on main[89d5]::main BISECT: running pass (21) SimplifyCfg-final on main[89d5]::main BISECT: running pass (22) CopyProp on main[89d5]::main BISECT: running pass (23) SimplifyLocals-final on main[89d5]::main BISECT: running pass (24) AddCallGuards on main[89d5]::main BISECT: running pass (25) PreCodegen on main[89d5]::main BISECT: running pass (26) CheckAlignment on main[89d5]::abs BISECT: running pass (27) CheckNull on main[89d5]::abs BISECT: running pass (28) CheckEnums on main[89d5]::abs BISECT: running pass (29) LowerSliceLenCalls on main[89d5]::abs BISECT: running pass (30) InstSimplify-before-inline on main[89d5]::abs BISECT: NOT running pass (31) ForceInline on main[89d5]::abs BISECT: NOT running pass (32) RemoveStorageMarkers on main[89d5]::abs BISECT: NOT running pass (33) RemoveZsts on main[89d5]::abs BISECT: NOT running pass (34) RemoveUnneededDrops on main[89d5]::abs BISECT: NOT running pass (35) UnreachableEnumBranching on main[89d5]::abs BISECT: NOT running pass (36) SimplifyCfg-after-unreachable-enum-branching on main[89d5]::abs BISECT: NOT running pass (37) InstSimplify-after-simplifycfg on main[89d5]::abs BISECT: NOT running pass (38) SimplifyConstCondition-after-inst-simplify on main[89d5]::abs BISECT: NOT running pass (39) SimplifyLocals-before-const-prop on main[89d5]::abs BISECT: NOT running pass (40) SimplifyLocals-after-value-numbering on main[89d5]::abs BISECT: NOT running pass (41) MatchBranchSimplification on main[89d5]::abs BISECT: NOT running pass (42) SingleUseConsts on main[89d5]::abs BISECT: NOT running pass (43) SimplifyConstCondition-after-const-prop on main[89d5]::abs BISECT: NOT running pass (44) SimplifyConstCondition-final on main[89d5]::abs BISECT: NOT running pass (45) RemoveNoopLandingPads on main[89d5]::abs BISECT: NOT running pass (46) SimplifyCfg-final on main[89d5]::abs BISECT: NOT running pass (47) CopyProp on main[89d5]::abs BISECT: NOT running pass (48) SimplifyLocals-final on main[89d5]::abs BISECT: NOT running pass (49) AddCallGuards on main[89d5]::abs BISECT: NOT running pass (50) PreCodegen on main[89d5]::abs ``` r? @saethlin
tests/ui/test-attrs: add annotations for reference rules
std: use libc version of `_NSGetArgc`/`_NSGetArgv` These were added to libc in rust-lang/libc#3702.
resolve: Disable an assert that no longer holds Fixes rust-lang/rust#152606 Fixes rust-lang/rust#152595
Rework explanation of CLI lint level flags I think the previous wording as either wrong or confusing. I would consider the CLI flags at a *lower* ranking, since source attributes are able to override the CLI flag.
add regression test for 147958 fixes rust-lang/rust#147958
…-incompatible-args, r=Kivooeo Fix ICE in `suggest_param_env_shadowing` with incompatible args Fixes rust-lang/rust#152684
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`. Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Miri: recursive validity: also recurse into Boxes Now that rust-lang/rust#97270 is fixed, the recursive validity mode for Miri can recuse into Boxes without exploding everywhere.
carryless_mul: mention the base Arithmetic operations do not typically care about the base that is used to represent numbers, but this one does. Mentioning that makes it easier to understand the operation, I think. Cc @folkertdev
Update tracking issue number for final_associated_functions From rust-lang/rust#151783 (comment)
Rollup of 20 pull requests Successful merges: - rust-lang/rust#145399 (Unify wording of resolve error) - rust-lang/rust#150473 (tail calls: fix copying non-scalar arguments to callee) - rust-lang/rust#152637 (Add a note about elided lifetime) - rust-lang/rust#152729 (compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness") - rust-lang/rust#152751 (Rename dep node "fingerprints" to distinguish key and value hashes) - rust-lang/rust#152753 (remove the explicit error for old `rental` versions) - rust-lang/rust#152758 (Remove ShallowInitBox.) - rust-lang/rust#151530 (Fix invalid `mut T` suggestion for `&mut T` in missing lifetime error) - rust-lang/rust#152179 (Add documentation note about signed overflow direction) - rust-lang/rust#152474 (Implement opt-bisect-limit for MIR) - rust-lang/rust#152509 (tests/ui/test-attrs: add annotations for reference rules) - rust-lang/rust#152672 (std: use libc version of `_NSGetArgc`/`_NSGetArgv`) - rust-lang/rust#152711 (resolve: Disable an assert that no longer holds) - rust-lang/rust#152725 (Rework explanation of CLI lint level flags) - rust-lang/rust#152732 (add regression test for 147958) - rust-lang/rust#152745 (Fix ICE in `suggest_param_env_shadowing` with incompatible args) - rust-lang/rust#152749 (make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute) - rust-lang/rust#152756 (Miri: recursive validity: also recurse into Boxes) - rust-lang/rust#152770 (carryless_mul: mention the base) - rust-lang/rust#152778 (Update tracking issue number for final_associated_functions)
Stabilize `if let` guards (`feature(if_let_guard)`) ## Summary This proposes the stabilization of `if let` guards (tracking issue: rust-lang/rust#51114, RFC: rust-lang/rfcs#2294). This feature allows `if let` expressions to be used directly within match arm guards, enabling conditional pattern matching within guard clauses. ## What is being stabilized The ability to use `if let` expressions within match arm guards. Example: ```rust enum Command { Run(String), Stop, Pause, } fn process_command(cmd: Command, state: &mut String) { match cmd { Command::Run(name) if let Some(first_char) = name.chars().next() && first_char.is_ascii_alphabetic() => { // Both `name` and `first_char` are available here println!("Running command: {} (starts with '{}')", name, first_char); state.push_str(&format!("Running {}", name)); } Command::Run(name) => { println!("Cannot run command '{}'. Invalid name.", name); } Command::Stop if state.contains("running") => { println!("Stopping current process."); state.clear(); } _ => { println!("Unhandled command or state."); } } } ``` ## Motivation The primary motivation for `if let` guards is to reduce nesting and improve readability when conditional logic depends on pattern matching. Without this feature, such logic requires nested `if let` statements within match arms: ```rust // Without if let guards match value { Some(x) => { if let Ok(y) = compute(x) { // Both `x` and `y` are available here println!("{}, {}", x, y); } } _ => {} } // With if let guards match value { Some(x) if let Ok(y) = compute(x) => { // Both `x` and `y` are available here println!("{}, {}", x, y); } _ => {} } ``` ## Implementation and Testing The feature has been implemented and tested comprehensively across different scenarios: ### Core Functionality Tests **Scoping and variable binding:** - [`scope.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs) - Verifies that bindings created in `if let` guards are properly scoped and available in match arms - [`shadowing.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs) - Tests that variable shadowing works correctly within guards - [`scoping-consistency.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scoping-consistency.rs) - Ensures temporaries in guards remain valid for the duration of their match arms **Type system integration:** - [`type-inference.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/type-inference.rs) - Confirms type inference works correctly in `if let` guards - [`typeck.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/typeck.rs) - Verifies type mismatches are caught appropriately **Pattern matching semantics:** - [`exhaustive.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/exhaustive.rs) - Validates that `if let` guards are correctly handled in exhaustiveness analysis - [`move-guard-if-let.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let.rs) and [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs) - Test that conditional moves in guards are tracked correctly by the borrow checker ### Error Handling and Diagnostics - [`warns.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/warns.rs) - Tests warnings for irrefutable patterns and unreachable code in guards - [`parens.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs) - Ensures parentheses around `let` expressions are properly rejected - [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs) - Verifies macro expansions that produce invalid constructs are caught - [`guard-mutability-2.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/guard-mutability-2.rs) - Tests mutability and ownership violations in guards - [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs) - Validates AST-level syntax restrictions ### Drop Order and Temporaries **Key insight:** Unlike `let_chains` in regular `if` expressions, `if let` guards do not have drop order inconsistencies because: 1. Match guards are clearly scoped to their arms 2. There is no "else block" equivalent that could cause temporal confusion - [`drop-order.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/drop-order.rs) - Check drop order of temporaries create in match guards - [`compare-drop-order.rs`](https://github.com/rust-lang/rust/blob/aef3f5fdf052fbbc16e174aef5da6d50832ca316/tests/ui/rfcs/rfc-2294-if-let-guard/compare-drop-order.rs) - Compares drop order between `if let` guards and nested `if let` in match arms, confirming they behave identically across all editions - rust-lang/rust#140981 - A complicated drop order test involved `let chain` was made by @est31 - [`drop-order-comparisons-let-chains.rs`](https://github.com/rust-lang/rust/blob/902b4d28783e03e231d8513082cc30c4fcce5d95/tests/ui/drop/drop-order-comparisons-let-chains.rs) - Compares drop order between `let chains` in `if let guard` and regular `if` expressions - [`if-let-guards.rs`](https://github.com/rust-lang/rust/blob/5650d716e0589e2e145ce9027f35bd534e5f862a/tests/ui/drop/if-let-guards.rs) - Test correctness of drop order for bindings and temporaries - [`if-let-guards-2`](https://github.com/rust-lang/rust/blob/3a6c8c8f3d7ae654fdb6ce1255182bda21680655/tests/ui/drop/if-let-guards-2.rs) - The same test as above but more comprehensive and tests more interactions between different features and their drop order, checking that drop order is correct, created by @traviscross ## Edition Compatibility This feature stabilizes on all editions, unlike `let chains` which was limited to edition 2024. This is safe because: 1. `if let` guards don't suffer from the drop order issues that affected `let chains` in regular `if` expressions 2. The scoping is unambiguous - guards are clearly tied to their match arms 3. Extensive testing confirms identical behavior across all editions ## Interactions with Future Features The lang team has reviewed potential interactions with planned "guard patterns" and determined that stabilizing `if let` guards now does not create obstacles for future work. The scoping and evaluation semantics established here align with what guard patterns will need. ## Unresolved Issues - [x] - rust-lang/rust#140981 - [x] - added tests description by @jieyouxu request - [x] - Concers from @scottmcm about stabilizing this across all editions - [x] - check if drop order in all edition when using `let chains` inside `if let` guard is the same - [x] - interactions with guard patters - [x] - pattern bindings drops before guard bindings rust-lang/rust#143376 - [x] - documentaion (rust-lang/reference#1957) - [ ] (non-blocking) add tests for [this](rust-lang/rust#145237) and [this](rust-lang/rust#141295 (comment)) --- **Related:** - Tracking Issue: rust-lang/rust#51114 - RFC: rust-lang/rfcs#2294 - Documentation PR: rust-lang/reference#1957
This updates the rust-version file to e0cb264b814526acb82def4b5810e394a2ed294f.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@e0cb264 Filtered ref: 291e6e9 Upstream diff: rust-lang/rust@8387095...e0cb264 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge ref 'e0cb264b8145' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: rust-lang/rust@e0cb264
Filtered ref: 291e6e9
Upstream diff: rust-lang/rust@8387095...e0cb264
This merge was created using https://github.com/rust-lang/josh-sync.