Trigger "C array" parse error recovery in far fewer cases by fmease · Pull Request #162705 · rust-lang/rust

fmease · 2026-09-13T00:09:44Z

Previously we would trigger on

unsafe { 1, 2, 3 } and suggest [ { 1, 2, 3 ] (sic!)
'label: { 1, 2, 3 } and suggest [: { 1, 2, 3 ] (sic!)
X::<{ 1, 2, 3 }> and suggest X::<[ 1, 2, 3]> (wrong)
|| -> i32 { 1, 2, 3 } and suggest || -> i32 [ 1, 2, 3 ] (wrong)
await { 1, 2, 3 } and suggest await [ 1, 2, 3 ] (wrong)

Moreover, stop looking for identifiers after the { as that case can no longer be reached anyway as maybe_recover_bad_struct_literal_path will always snatch it first.

I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise.

_{(No LLM was or will be used by me during the entire creation process of this PR)}

rustbot · 2026-09-13T00:09:48Z

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, parser
compiler, parser expanded to 76 candidates
Random selection from 19 candidates

JonathanBrouwer · 2026-09-18T09:33:49Z

I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise.

I'm personally of the opinion that more tests are always better than fewer tests, I'm wondering what your reasoning is there.
It would be a shame if someone in the future tweaks this recovery further and accidentally breaks this again.
Personally, I'd add all the examples in the description to the issue-87830-try-brackets-for-arrays test.

r=me with a regression test
@rustbot author

fmease · 2026-09-19T15:10:23Z

This PR was the result of a side quest of a side quest of a side quest while I was on a cleanup spree in the parser axing things left & right, so I just didn't feel like adding any code / creating patches where lines added >= lines removed :D

rustbot · 2026-09-19T15:18:48Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

fmease · 2026-09-19T15:19:12Z

Test cases added to the existing test file.

@bors r=JonathanBrouwer rollup

rust-bors · 2026-09-19T15:19:14Z

📌 Commit 8a0a23d has been approved by JonathanBrouwer

It is now in the queue for this repository.

Previously we would trigger on 1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!) 2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!) 3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong) 4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong) 5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong) Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first.

…nBrouwer Trigger "C array" parse error recovery in far fewer cases Previously we would trigger on 1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!) 2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!) 3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong) 4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong) 5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong) Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first. I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise. (No LLM was or will be used by me during the entire creation process of this PR)

Rollup of 6 pull requests Successful merges: - #162228 (tests: Run more pauth tests in CI and make them pass) - #162990 (post GH comment on types nominations) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162988 (recover `true` and `false` in type position as `bool`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone)

…nBrouwer Trigger "C array" parse error recovery in far fewer cases Previously we would trigger on 1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!) 2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!) 3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong) 4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong) 5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong) Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first. I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise. (No LLM was or will be used by me during the entire creation process of this PR)

Rollup of 13 pull requests Successful merges: - #158515 (Make let-else respect macro_rules expr metavariable grouping) - #160097 (fix const_item_mutation lint to use needs_drop instead of has_dtor) - #161435 (Provide a `supertrait_def_ids()` function in rustc_type_ir's interner) - #161894 (Do not suppress the fn item uniqueness note for late bound lifetimes) - #162990 (post GH comment on types nominations) - #154665 (add safety section for mem::zeroed) - #162700 ( Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162875 (Add .seek_read_exact(), .seek_write_all() to std::os::windows::fs::FileExt) - #162988 (recover `true` and `false` in type position as `bool`) - #162995 (Constify `impl FromStr for NonZero<T>`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone)

…nBrouwer Trigger "C array" parse error recovery in far fewer cases Previously we would trigger on 1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!) 2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!) 3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong) 4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong) 5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong) Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first. I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise. (No LLM was or will be used by me during the entire creation process of this PR)

…uwer Rollup of 15 pull requests Successful merges: - #158515 (Make let-else respect macro_rules expr metavariable grouping) - #162726 (std: fix unix socket address panic on a full sun_path) - #160028 (Better account for `Self` that might be a typo of `self`) - #160097 (fix const_item_mutation lint to use needs_drop instead of has_dtor) - #161435 (Provide a `supertrait_def_ids()` function in rustc_type_ir's interner) - #161894 (Do not suppress the fn item uniqueness note for late bound lifetimes) - #162990 (post GH comment on types nominations) - #154665 (add safety section for mem::zeroed) - #162700 ( Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162875 (Add .seek_read_exact(), .seek_write_all() to std::os::windows::fs::FileExt) - #162988 (recover `true` and `false` in type position as `bool`) - #162995 (Constify `impl FromStr for NonZero<T>`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone)

Rollup of 17 pull requests Successful merges: - #158515 (Make let-else respect macro_rules expr metavariable grouping) - #160028 (Better account for `Self` that might be a typo of `self`) - #160097 (fix const_item_mutation lint to use needs_drop instead of has_dtor) - #161435 (Provide a `supertrait_def_ids()` function in rustc_type_ir's interner) - #161894 (Do not suppress the fn item uniqueness note for late bound lifetimes) - #162990 (post GH comment on types nominations) - #153662 (Suggest fully qualified path on method name collision) - #154665 (add safety section for mem::zeroed) - #159787 (Prefer ModId in more places) - #162700 ( Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162875 (Add .seek_read_exact(), .seek_write_all() to std::os::windows::fs::FileExt) - #162988 (recover `true` and `false` in type position as `bool`) - #162995 (Constify `impl FromStr for NonZero<T>`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone) - #163039 (Use verbose suggestion for parenthetical `Fn` notation and fully-qualified path on ambiguous assoc item)

Rollup merge of #162705 - fmease:fix-c-array-diag, r=JonathanBrouwer Trigger "C array" parse error recovery in far fewer cases Previously we would trigger on 1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!) 2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!) 3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong) 4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong) 5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong) Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first. I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise. (No LLM was or will be used by me during the entire creation process of this PR)

rustbot assigned JonathanBrouwer Sep 13, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 13, 2026

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 18, 2026

fmease force-pushed the fix-c-array-diag branch from eb2d4a7 to 8a0a23d Compare September 19, 2026 15:18

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 19, 2026

jhpratt mentioned this pull request Sep 19, 2026

Rollup of 6 pull requests #163033

Closed

jhpratt mentioned this pull request Sep 19, 2026

Rollup of 13 pull requests #163035

Closed

JonathanBrouwer mentioned this pull request Sep 19, 2026

Rollup of 15 pull requests #163038

Closed

mu001999 mentioned this pull request Sep 20, 2026

Rollup of 17 pull requests #163043

Merged

rust-bors Bot merged commit 5435e38 into rust-lang:main Sep 20, 2026
13 checks passed

rustbot added this to the 1.100.0 milestone Sep 20, 2026

fmease deleted the fix-c-array-diag branch September 20, 2026 13:25

github-actions Bot mentioned this pull request Oct 2, 2026

Toolchain upgrade to nightly-2026-09-25 flux-rs/flux#1803

Merged

Navigation Menu

Repository navigation

Trigger "C array" parse error recovery in far fewer cases - #162705

Trigger "C array" parse error recovery in far fewer cases#162705
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
fmease:fix-c-array-diag

fmease commented Sep 13, 2026

Uh oh!

rustbot commented Sep 13, 2026

Uh oh!

JonathanBrouwer commented Sep 18, 2026 •

edited

Loading

Uh oh!

fmease commented Sep 19, 2026 •

edited

Loading

Uh oh!

rustbot commented Sep 19, 2026

Uh oh!

fmease commented Sep 19, 2026

Uh oh!

rust-bors Bot commented Sep 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

fmease commented Sep 13, 2026

Uh oh!

rustbot commented Sep 13, 2026

Uh oh!

JonathanBrouwer commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease commented Sep 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 19, 2026

Uh oh!

fmease commented Sep 19, 2026

Uh oh!

rust-bors Bot commented Sep 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JonathanBrouwer commented Sep 18, 2026 •

edited

Loading

fmease commented Sep 19, 2026 •

edited

Loading