Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription by fmease · Pull Request #162700 · rust-lang/rust

fmease · 2026-09-12T21:12:01Z

Back when we still had type ascription syntax $expr : $ty, parse_assoc_op_cast would parse both as casts & type ascription.

During that time (namely in commit 8c5dafd), parse error recovery from code like label: loop {} was added (label lacks leading apostrophe). However, it never checked if we did actually parse a : and not an as meaning to this day we emit a nonsensical diagnostic for expressions like label as loop {}! This PR does away with this code & further cleans up in the area (thanks to type ascription being gone).

In case you're wondering, we do still recover from expr stmts like label: loop {} as we have some code in the stmt parser for this.

Since the removal of the type ascription syntax we do indeed no longer provide that recovery for arbitrary exprs (e.g, (label: loop {})) which I find absolutely acceptable.

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

rustbot · 2026-09-12T21:12:06Z

r? @fee1-dead

rustbot has assigned @fee1-dead.
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 21 candidates

chenyukang · 2026-09-13T01:12:56Z

link #101728

chenyukang · 2026-09-13T01:23:34Z

maybe add a ui test for it since there is a observable change on diagnostics.

fmease · 2026-09-13T18:22:03Z

maybe add a ui test for it since there is a observable change on diagnostics.

I'm usually pro tests (of course) but in cases like here (or over there: #162704) I'm less in favor since the larger context is me being on a spree to dejank the parser trying to shave off as much crusty code as possible (cc #162269, #161796).

How likely would it be for label as loop {} to regress again? I believe it's 0% because we've de-RFC'ed $expr : $ty as you obviously know. So what would the odds be? It's just a lot more satisfying to have diffs where removed>>added ^^' Adding a regression test that in my eyes doesn't bear any value would make a dent in that.

…or the long removed type ascription

rustbot · 2026-09-19T14:38:00Z

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.

fee1-dead · 2026-09-19T18:15:22Z

Sorry for the late reply, LGTM!

@bors r+ rollup

rust-bors · 2026-09-19T18:15:24Z

📌 Commit e224f8f has been approved by fee1-dead

It is now in the queue for this repository.

…dead Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription Back when we still had type ascription syntax `$expr : $ty`, `parse_assoc_op_cast` would parse both `as` casts & type ascription. During that time (namely in commit rust-lang@8c5dafd), parse error recovery from code like `label: loop {}` was added (label lacks leading apostrophe). However, it never checked if we did actually parse a `:` and not an `as` meaning *to this day* we emit a nonsensical diagnostic for expressions like `label as loop {}`! This PR does away with this code & further cleans up in the area (thanks to type ascription being gone). In case you're wondering, we do still recover from expr *stmts* like `label: loop {}` as we have some code in the stmt parser for this. Since the removal of the type ascription syntax we do indeed no longer provide that recovery for arbitrary exprs (e.g, `(label: loop {})`) which I find absolutely acceptable. (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)

…dead Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription Back when we still had type ascription syntax `$expr : $ty`, `parse_assoc_op_cast` would parse both `as` casts & type ascription. During that time (namely in commit rust-lang@8c5dafd), parse error recovery from code like `label: loop {}` was added (label lacks leading apostrophe). However, it never checked if we did actually parse a `:` and not an `as` meaning *to this day* we emit a nonsensical diagnostic for expressions like `label as loop {}`! This PR does away with this code & further cleans up in the area (thanks to type ascription being gone). In case you're wondering, we do still recover from expr *stmts* like `label: loop {}` as we have some code in the stmt parser for this. Since the removal of the type ascription syntax we do indeed no longer provide that recovery for arbitrary exprs (e.g, `(label: loop {})`) which I find absolutely acceptable. (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 #162700 - fmease:rm-dead-ascr-recov, r=fee1-dead Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription Back when we still had type ascription syntax `$expr : $ty`, `parse_assoc_op_cast` would parse both `as` casts & type ascription. During that time (namely in commit 8c5dafd), parse error recovery from code like `label: loop {}` was added (label lacks leading apostrophe). However, it never checked if we did actually parse a `:` and not an `as` meaning *to this day* we emit a nonsensical diagnostic for expressions like `label as loop {}`! This PR does away with this code & further cleans up in the area (thanks to type ascription being gone). In case you're wondering, we do still recover from expr *stmts* like `label: loop {}` as we have some code in the stmt parser for this. Since the removal of the type ascription syntax we do indeed no longer provide that recovery for arbitrary exprs (e.g, `(label: loop {})`) which I find absolutely acceptable. (No LLM was or will be used by me during the entire creation process of this PR)

fmease added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Sep 12, 2026

rustbot assigned fee1-dead Sep 12, 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 12, 2026

This comment has been minimized.

Sign in to view

Remove incorrect parse error recovery code that mistakes as casts f…

6524ec5

…or the long removed type ascription

fmease force-pushed the rm-dead-ascr-recov branch from f97a732 to e224f8f Compare September 19, 2026 14:37

Further simplify parse_assoc_op_cast

e224f8f

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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 19, 2026

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 a49b3c8 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 rm-dead-ascr-recov branch September 20, 2026 13:26

Navigation Menu

Uh oh!

Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription - #162700

Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription#162700
rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
fmease:rm-dead-ascr-recov

fmease commented Sep 12, 2026 •

edited

Loading

Uh oh!

rustbot commented Sep 12, 2026

Uh oh!

chenyukang commented Sep 13, 2026

Uh oh!

chenyukang commented Sep 13, 2026

Uh oh!

fmease commented Sep 13, 2026 •

edited

Loading

Uh oh!

This comment has been minimized.

rustbot commented Sep 19, 2026

Uh oh!

fee1-dead 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!

4 participants

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Sep 12, 2026

Uh oh!

chenyukang commented Sep 13, 2026

Uh oh!

chenyukang commented Sep 13, 2026

Uh oh!

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

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Sep 19, 2026

Uh oh!

fee1-dead 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!

4 participants

fmease commented Sep 12, 2026 •

edited

Loading

fmease commented Sep 13, 2026 •

edited

Loading