e2b66ef351
add regression test for unicode dotdotdot rest pattern
2026-05-09 01:27:23 +09:00
11d88ee42b
Rip out rustc_layout_scalar_valid_range_* attribute support
2026-05-03 10:59:52 +02:00
8ee783610d
Rollup merge of #154325 - WeiTheShinobi:tweak-let-else-output, r=davidtwco
...
Tweak irrefutable let else warning output
Fixes https://github.com/rust-lang/rust/issues/153454
Greeting!
This PR tweak diagnostic output for `irrefutable-let-else` patterns and adds a check for `let a = Some(b) else {...}`
Thanks for the review!
```
help: consider using `let Some(name) = case` to match on a specific variant
|
LL - let name = Some(case) else {
LL + let Some(name) = case else {
|
```
2026-04-28 20:24:30 +02:00
9ceed255b5
Avoid improper spans when ... or ..= is recovered from non-ASCII
...
This avoids an ICE due to indexing into the middle of a multi-byte character.
2026-04-26 21:41:46 +10:00
f107bb85a2
Regression test for improper spans in inclusive-range suggestions
2026-04-26 21:36:51 +10:00
1230f74ad5
Rollup merge of #155698 - fmease:no-struct-pat-tuple-index-shorthand, r=mu001999
...
Syntactically reject tuple index shorthands in struct patterns to fix a correctness regression
Split out of PR rust-lang/rust#154492 . This fixes a correctness regression introduced in PR rust-lang/rust#81235 from 2021. Crater was run in my other PR and didn't report any real regressions (https://github.com/rust-lang/rust/pull/154492#issuecomment-4187544786 ); a rerun has been issued for a few spurious builds (https://github.com/rust-lang/rust/pull/154492#issuecomment-4237077272 ) but I'm certain it won't find anything either.
This is a theoretical breaking change that doesn't need any T-lang input IMHO since it's such a minute, niche and crystal clear bug that's not worth bothering them with (such a decision is not unprecedented). I'm adding it to the compatibility section of the release notes as is customary.
The Reference doesn't need updating since it didn't adopt this bug and thus accurately describes this part of the grammar as it used to be before 2021-02-23 and as it's meant to be.
The majority of the diff is doc comment additions & necessary UI test restructurings.
2026-04-24 02:42:52 -04:00
07d015e566
Syntactically reject tuple index shorthands in struct patterns to fix a correctness regression
2026-04-23 22:28:00 +02:00
8c3864b6cc
Rollup merge of #155561 - cijiugechu:fix/need-type-info-underscore-wording, r=adwinwhite
...
Use singular wording for single _ placeholders in type suggestions
While looking this part of code, I noticed this FIXME and fixed it :)
2026-04-23 14:42:48 +02:00
24b1634898
BinOpAssign always returns unit
2026-04-22 12:27:03 +02:00
69dae5941e
Update shebang reference rule names
...
This updates the rule names for shebang which were changed in
rust-lang/reference#2192 and rust-lang/reference#2199 .
2026-04-20 15:08:37 -07:00
ffcbfc1cf4
Use singular wording for single _ placeholders in type suggestions
2026-04-20 22:21:51 +08:00
8591f0f230
Tweak irrefutable let else warning output, add new suggestion
2026-04-18 13:03:47 +08:00
c729f33e46
Rollup merge of #155078 - cijiugechu:fix/where-clause-trailing-attrs, r=petrochenkov
...
Reject dangling attributes in where clauses
Report `attribute without where predicates` for trailing outer attributes in where clauses.
Closes rust-lang/rust#155073 .
2026-04-10 18:38:12 +02:00
3c6cf27ae4
Reject dangling attributes in where clauses
2026-04-10 21:45:26 +08:00
65745a1b95
Revert #152369 because of multiple regressions
...
The regressions are documented in the PR comments.
This reverts commit 2972b5ef908263
2026-04-09 18:53:59 +02:00
63ed113d84
chore: Update annotate-snippets to 0.12.15
2026-04-06 14:48:52 -06:00
77a5cb0194
Rollup merge of #154561 - FranciscoTGouveia:typo-detection-after-visibility, r=TaKO8Ki
...
Suggest similar keyword when visibility is not followed by an item
Fixes rust-lang/rust#153353 .
I would appreciate feedback on the following:
- I inlined [`find_similar_kw`](https://github.com/rust-lang/rust/blob/cd14b73b4a41542d921f59e362a5b5005fa4f2ef/compiler/rustc_parse/src/parser/diagnostics.rs#L218-L224 ) instead of changing its visibility to `pub(super)`. I am happy to switch if it is preferred;
- I didn't add a comment to the new test. Although the rustc-dev-guide specifies that a [comment should be added](https://rustc-dev-guide.rust-lang.org/tests/adding.html#comment-explaining-what-the-test-is-about ) to every new test, this is not common in `tests/ui/parser/misspelled_keywords/` and the test seems self-explanatory. Let me know if you would like me to add a comment;
Thank you in advance for your time and input!
2026-04-06 08:27:50 +02:00
bd864efa70
bless tests and tidy
...
also removes E0452 and splits
`tests/rustdoc-ui/lints/renamed-lint-still-applies` into 2 tests
this is because of delayed warn lint being lost on compiler aborting on
error
2026-04-03 11:08:11 +02:00
4b2aa6d93b
Rollup merge of #154527 - fmease:more-soft-gates, r=nnethercote
...
Emit pre-expansion feature gate warnings for negative impls and specialization
Follow up to rust-lang/rust#154475 ; part of rust-lang/rust#154045 .
This shouldn't need any extra input from T-compiler or T-lang since it's legitimized by [MCP 535](https://github.com/rust-lang/compiler-team/issues/535 ).
However, I have a feeling that negative impls & specialization behind "`#[cfg(feature = "nightly")]`" are more prevalent in the ecosystem compared to e.g., auto traits & box patterns, so these new warnings will probably hit a bunch of users. In any case, it's only a warning for now not an error so e.g., running crater "in deny mode" or nominating for a T-lang meeting discussion would be disproportionate (esp. since T-lang [has confirmed in the past](https://github.com/rust-lang/rust/pull/116393#issuecomment-1745571299 ) that this is a T-compiler matter).
2026-04-02 22:13:50 +02:00
009a6c1e8b
Auto merge of #154308 - ShoyuVanilla:undo-fudge-iv, r=jieyouxu
...
Revert #151380 and #153869
cc https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports/topic/.23153869.3A.20beta-nominated/with/581306395
r? ghost
2026-04-02 00:09:59 +00:00
92fbfae16b
Emit pre-expansion feature gate warning for item modifier default
2026-04-01 17:01:59 +02:00
7f53271474
Suggest similar keyword when visibility is not followed by an item
2026-03-29 21:16:08 +01:00
c2fc360b96
Rollup merge of #154504 - cyrgani:structenum, r=Kivooeo
...
move many tests from `structs-enums` to `structs` or `enum`
This PR moves most of the tests in `ui/structs-enums` that are only about structs or only about enums to their respective directory, as a step towards removing `ui/structs-enums`.
Followup to rust-lang/rust#154131 .
r? @Kivooeo
2026-03-29 00:06:53 +01:00
5bdde380cc
move many tests from structs-enums to structs or enum
2026-03-28 12:38:35 +00:00
7881a31ccf
Rollup merge of #152880 - JohnTitor:tweak-assoc-item-note, r=fmease
...
Tweak incorrect assoc item note
Fix rust-lang/rust#142797
r? @fmease
2026-03-28 13:15:48 +01:00
531631c7ad
Make messages more generic
2026-03-28 16:18:11 +09:00
16b9fddf00
Improve doc comment unicode guidance
2026-03-26 11:42:38 +08:00
d5bbeb978e
Revert "Auto merge of #151380 - ShoyuVanilla:shallow-resolve-to-root-var, r=lcnr"
...
This reverts commit 75b9d89c687bee525095
2026-03-24 22:31:37 +09:00
ae3d87c2a8
Update shebang reference names
...
This updates the rule names for shebang which were changed in
https://github.com/rust-lang/reference/pull/2192 and
https://github.com/rust-lang/reference/pull/2199 .
2026-03-23 14:28:42 -07:00
9b0be7857a
allow incomplete_features in most UI tests
2026-03-21 20:10:07 +00:00
3b27a36601
Suggest appropriate spaces around = in let binding parse error
2026-03-20 19:45:29 +00:00
244322f0be
Make : -> = typo suggestion verbose
2026-03-20 19:07:28 +00:00
87d8f5885b
Provide more context on type errors in const context
...
- On `const` and `static` point at the type (like we do for let bindings)
- On fn calls, point at const parameter in fn definition
- On type, point at const parameter in type definition
- On array type lengths, explain that array length is always `usize`
- On enum variant discriminant, mention `repr`
2026-03-14 20:13:43 +00:00
9e97c57cc8
relocate several ui tests
2026-03-13 10:00:39 +00:00
cecc5e7cea
Rollup merge of #153346 - WaffleLapkin:sometimes-test, r=jieyouxu
...
move never type tests to subdirectories and add some comments
This hopefully makes things a little bit clearer
2026-03-07 01:42:36 +01:00
05174fbcc5
tidy never type issue-* tests
2026-03-06 17:44:18 +01:00
eef3c4db7b
move never type tests to subdirectories and add some comments
2026-03-04 13:17:19 +01:00
70287b9bc2
Rollup merge of #153048 - ozankenangungor:fix-irrefutable-let-else-wording, r=Kivooeo
...
Improve irrefutable let-else lint wording
Update the `irrefutable_let_patterns` wording for let-else to better reflect that the `else` clause is unreachable when the LHS pattern always matches.
Closes rust-lang/rust#152938
2026-03-04 11:54:09 +11:00
87bd517707
Rollup merge of #153034 - arferreira:fix-trivial-bound-diagnostic, r=Kivooeo
...
Remove unhelpful hint from trivial bound errors
The `= help: see issue #48214` hint on trivial bound errors isn't useful, most users hitting these errors aren't trying to use the `trivial_bounds` feature. The `disabled_nightly_features` call already handles suggesting the feature gate on nightly.
Closes rust-lang/rust#152872
2026-03-03 07:14:15 +01:00
a8d4eeef1b
Improve irrefutable let-else lint wording
2026-03-03 03:39:56 +03:00
f5d3b158b9
Don’t report missing fields in struct exprs with syntax errors.
...
This prevents spurious errors when a field is intended to be present
but a preceding syntax error caused it not to be parsed. For example,
StructName { foo: 1 bar: 2 }
will not successfully parse a field `bar`, and we will report the syntax
error but not the missing field.
2026-02-28 20:32:20 -08:00
6f54d591c3
Auto merge of #151247 - chenyukang:yukang-fix-const-recover-151149, r=estebank
...
Try to recover from over-parsing in const item with missing semicolon
Fixes rust-lang/rust#151149
r? @estebank
2026-02-27 09:09:21 +00:00
d3bd9e6103
Remove unhelpful hint from trivial bound errors
2026-02-24 00:04:45 -05:00
0b5290123d
Update uitests
2026-02-22 20:20:33 +01:00
9330931a2b
Rollup merge of #152596 - estebank:multipart_suggestions, r=petrochenkov
...
Make all multipart suggestions verbose
The ShowAlways style of suggestions is usually easier to understand than the inline style.
2026-02-19 10:56:37 +01:00
e0cb264b81
Auto merge of #141295 - Kivooeo:if-let-guard-stable, r=fee1-dead,est31
...
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 https://github.com/rust-lang/rust/pull/143376
- [x] - documentaion (https://github.com/rust-lang/reference/pull/1957 )
- [ ] (non-blocking) add tests for [this](https://github.com/rust-lang/rust/issues/145237 ) and [this](https://github.com/rust-lang/rust/pull/141295#issuecomment-3173059821 )
---
**Related:**
- Tracking Issue: rust-lang/rust#51114
- RFC: rust-lang/rfcs#2294
- Documentation PR: https://github.com/rust-lang/reference/pull/1957
2026-02-18 20:49:50 +00:00
37684bdfc5
Make all multipart suggestions verbose
...
The ShowAlways style of suggestions is usually easier to understand than the inline style.
2026-02-18 18:33:35 +00:00
c73b3d20c6
Unify wording of resolve error
...
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`
```
2026-02-17 16:51:44 +00:00
1367126837
Rollup merge of #151783 - mu001999-contrib:impl/final-method, r=fee1-dead
...
Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802 , with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678 .
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
2026-02-17 13:02:21 +11:00
964b63f42e
if let guard stabilize
2026-02-16 12:24:15 +00:00
Takayuki Maeda