Parser: Recover from attributes applied to types and generic args #144195

Kivooeo · 2025-07-19T22:02:56Z

r? compiler

Add clearer error messages for invalid attribute usage in types or generic types

compiler-errors · 2025-07-20T16:58:04Z

compiler/rustc_parse/src/parser/ty.rs

+            while self.token != token::CloseBracket && self.token != token::Eof {
+                self.bump();
+            }


The logic here is pretty strange.

Why wouldn't we just go through the normal parsing routine to parse an attr, then go through the normal parsing routine to parse a type?

Oh, honestly didn't know about "normal parsing routine" and just go manually parsing, do you mean "parse_outer_attributes"?

Yeah probably something like that. Look at how we parse item attrs for example.

Let's see if I'm on a right way, firstly implemented it for generic then just copied for regular type, based on tests it seems works fine

Thinking about it now, maybe I could yeet that logic into a helper function and not duplicate code, but first need your opinion on logic itself, but I'm out for now

compiler-errors · 2025-07-20T16:58:21Z

compiler/rustc_parse/src/parser/ty.rs

+
+            let span = lo_attr.to(self.prev_token.span);
+
+            if self.token.is_ident() {


Specifically, this only works if the type is an ident. We have lots of other types to handle here.

Why not just try parsing an attr eagerly at the beginning of parse_ty_common, and then there doesn't need to be a special branch in this if chain?

compiler-errors · 2025-07-20T17:00:23Z

r? compiler-errors

compiler/rustc_parse/src/parser/path.rs

Kivooeo · 2025-07-21T12:45:09Z

~~I'm genuinely curious about case where we have attribute in generic but don't have argument, what would ideal error in such case?~~

~~I'm not sure if we want to recover after finding a attribute, becuase it's always a wrong code and it's lead to case like this~~

Well I added a branch to handle this (you can see it in review below)

error[E0107]: struct takes 1 generic argument but 0 generic arguments were supplied
 --> src/main.rs:4:12
  |
4 |     let _: Baz<#[cfg(any())]> = todo!();
  |            ^^^ expected 1 generic argument
  |
note: struct defined here, with 1 generic parameter: `N`
 --> src/main.rs:1:8
  |
1 | struct Baz<const N: usize>(i32);
  |        ^^^ --------------
help: add missing generic argument
  |
4 |     let _: Baz<N#[cfg(any())]> = todo!();
  |                +

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0107`.

compiler/rustc_parse/src/parser/path.rs

tests/ui/parser/attribute-on-type.stderr

tests/ui/parser/attribute-on-type.rs

compiler/rustc_parse/src/parser/attr_wrapper.rs

Kivooeo

I've called out the potentially surprising bits of this implementation with explanations to help reviewers in mine this and above reviews

tests/ui/parser/attribute-on-type.stderr

tests/ui/parser/recover/recover-where-clause-before-tuple-struct-body-0.fixed

tests/ui/parser/attribute-on-type.rs

Kivooeo · 2025-07-29T20:48:27Z

@fmease, I spent significant time trying to address the secondary error you mentioned. Good news: I solved it for cases where there's something inside the generic. When we have Baz<#[cfg(any())] 42>, we can now match on what we parsed and return the right GenericArg type. This eliminates the secondary error problem.

But I hit a wall with empty generics like Baz<#[cfg(any())]>.

The problem is ty_generics is always None during parsing. The parser hasn't done name resolution yet as far I understand that process correctly, so it doesn't know what Baz actually expects. When we see an empty generic with just an attribute, we have to guess whether to return type, const or lifetime.

Whatever we pick will be wrong sometimes. If I default to GenericArg::Type, then Baz<#[attr]> gives "type provided when constant expected." If I default to GenericArg::Const, then Foo<#[attr]> gives "constant provided when type expected."

I can pick a statistical default (types are most common), but some cases will still get secondary errors. Is that acceptable, or do you see another approach I'm missing?

The architectural issue seems fundamental since parsing happens before we know what types expect what kinds of generics.

compiler/rustc_parse/src/parser/path.rs

compiler/rustc_parse/messages.ftl

compiler/rustc_parse/src/parser/path.rs

compiler/rustc_parse/src/errors.rs

tests/ui/parser/issues/issue-103143.rs

compiler/rustc_parse/src/errors.rs

Kivooeo · 2025-08-01T12:11:00Z

@rustbot ready

fmease

Final stretch, after that I'll approve.

compiler/rustc_parse/src/parser/attr_wrapper.rs

tests/ui/parser/recover/recover-where-clause-before-tuple-struct-body-0.rs

compiler/rustc_parse/src/errors.rs

fmease · 2025-08-04T22:08:49Z

compiler/rustc_parse/src/parser/path.rs

@@ -934,6 +941,9 @@ impl<'a> Parser<'a> {
            }
        } else if self.token.is_keyword(kw::Const) {
            return self.recover_const_param_declaration(ty_generics);
+        } else if let Some(attr_span) = attr_span {
+            let diag = self.dcx().create_err(AttributeOnEmptyType { span: attr_span });
+            return Err(diag);
        } else {
            // Fall back by trying to parse a const-expr expression. If we successfully do so,
            // then we should report an error that it needs to be wrapped in braces.


Two lines below, there's a preexisting let attrs = self.parse_outer_attributes()?;. We should be able to drop it and pass the already parsed attrs to the parse_expr_res.

It's not a blocking concern tho ig and it would stop us from recovering from /// and /** */ on gen args. Can be done in a follow-up.

compiler/rustc_parse/src/parser/path.rs

rustbot · 2025-08-05T02:01:32Z

⚠️ Warning ⚠️

This PR is based on an upstream commit that is 16 days old.

It's recommended to update your branch according to the rustc-dev-guide.

Kivooeo · 2025-08-05T02:11:48Z

Small breakdown what I've changed according to last reviews

Removed reduant comments
Renamed AttributeOnGenericType to AttributeOnGenericArg (and parse_attribute_on_generic_type to parse_attribute_on_generic_arg)
Deleted (my favourite function so far) attrs()
Use take_for_recovery instead of attrs
Fixed .fixed in some test with really long name
Exaplained on why we need this check on # and [

What I did not made

Refactored function as it was suggested here Parser: Recover from attributes applied to types and generic args #144195 (comment), because now after changed to take_for_recovery it will ICE if someone make changes to this function and break control flow somehow
Didn't accounted Parser: Recover from attributes applied to types and generic args #144195 (comment), I mean, I've tried to rewrite function to pass previosly parsed attrbute to this else block but then I found that if attribute was succesfull parsed at the start of function it will never get inside this else block because of else if above

Kivooeo · 2025-08-05T15:11:12Z

@rustbot ready

fmease · 2025-08-06T15:40:31Z

Thanks a lot!
@bors r=fmease,compiler-errors rollup

bors · 2025-08-06T15:40:34Z

📌 Commit d09cf61 has been approved by fmease,compiler-errors

It is now in the queue for this repository.

Rollup of 15 pull requests Successful merges: - #144195 (Parser: Recover from attributes applied to types and generic args) - #144794 (Port `#[coroutine]` to the new attribute system) - #144835 (Anonymize binders in tail call sig) - #144861 (Stabilize `panic_payload_as_str` feature) - #144917 (Enforce tail call type is related to body return type in borrowck) - #144948 (we only merge candidates for trait and normalizes-to goals) - #144956 (Gate const trait syntax) - #144970 (rustdoc: fix caching of intra-doc links on reexports) - #144972 (add code example showing that file_prefix treats dotfiles as the name of a file, not an extension) - #144975 (`File::set_times`: Update documentation and example to support setting timestamps on directories) - #144977 (Fortify generic param default checks) - #144996 (simplifycfg: Mark as changed when start is modified in collapse goto chain) - #144998 (mir: Do not modify NonUse in `super_projection_elem`) - #145000 (Remove unneeded `stage` parameter when setting up stdlib Cargo) - #145008 (Fix rustdoc scrape examples crash) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #144195 - Kivooeo:bad-attr, r=fmease,compiler-errors Parser: Recover from attributes applied to types and generic args r? compiler Add clearer error messages for invalid attribute usage in types or generic types fixes #135017 fixes #144132

rustbot assigned lcnr Jul 19, 2025

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 Jul 19, 2025

Kivooeo changed the title ~~Added checks for attributes in types~~ Add checks for attributes in types Jul 19, 2025

workingjubilee closed this Jul 20, 2025

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 20, 2025

workingjubilee reopened this Jul 20, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 20, 2025

compiler-errors requested changes Jul 20, 2025

View reviewed changes

rustbot assigned compiler-errors and unassigned lcnr Jul 20, 2025

Kivooeo force-pushed the bad-attr branch from 1119298 to 5d9c713 Compare July 20, 2025 18:34

This comment has been minimized.

Sign in to view

Kivooeo force-pushed the bad-attr branch 2 times, most recently from 5502794 to 2b4000d Compare July 20, 2025 20:12

fmease reviewed Jul 20, 2025

View reviewed changes

compiler/rustc_parse/src/parser/path.rs Outdated Show resolved Hide resolved

Kivooeo force-pushed the bad-attr branch 2 times, most recently from e267a23 to 516db8d Compare July 21, 2025 14:47

Kivooeo commented Jul 21, 2025

View reviewed changes

Kivooeo force-pushed the bad-attr branch from 516db8d to b107f87 Compare July 21, 2025 16:54

Kivooeo commented Jul 21, 2025

View reviewed changes

tests/ui/parser/attribute-on-type.stderr Outdated Show resolved Hide resolved

estebank reviewed Jul 23, 2025

View reviewed changes

tests/ui/parser/recover/recover-where-clause-before-tuple-struct-body-0.fixed Outdated Show resolved Hide resolved

estebank reviewed Jul 23, 2025

View reviewed changes

tests/ui/parser/attribute-on-type.rs Show resolved Hide resolved

fmease reviewed Jul 23, 2025

View reviewed changes

tests/ui/parser/attribute-on-type.rs Outdated Show resolved Hide resolved

Kivooeo force-pushed the bad-attr branch from b107f87 to 9169c32 Compare July 23, 2025 17:09

This comment has been minimized.

Sign in to view

Kivooeo force-pushed the bad-attr branch from 9169c32 to cdc8db4 Compare July 29, 2025 20:45

fmease reviewed Jul 30, 2025

View reviewed changes

compiler/rustc_parse/src/errors.rs Outdated Show resolved Hide resolved

Kivooeo force-pushed the bad-attr branch from cdc8db4 to e47dac2 Compare July 30, 2025 13:25

Kivooeo commented Jul 30, 2025

View reviewed changes

tests/ui/parser/issues/issue-103143.rs Outdated Show resolved Hide resolved

estebank reviewed Jul 30, 2025

View reviewed changes

compiler/rustc_parse/src/errors.rs Outdated Show resolved Hide resolved

compiler/rustc_parse/src/errors.rs Outdated Show resolved Hide resolved

Kivooeo force-pushed the bad-attr branch from e47dac2 to 2b75dbd Compare August 1, 2025 09:51

fmease self-assigned this Aug 4, 2025

fmease requested changes Aug 4, 2025

View reviewed changes

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 Aug 4, 2025

Kivooeo force-pushed the bad-attr branch from 2b75dbd to d66b773 Compare August 5, 2025 02:01

Added checks for attribute in type case

d09cf61

Kivooeo force-pushed the bad-attr branch from d66b773 to d09cf61 Compare August 5, 2025 02:10

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

fmease approved these changes Aug 6, 2025

View reviewed changes

bors 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 Aug 6, 2025

fmease changed the title ~~Add checks for attributes in types~~ Parser: Recover from attributes applied to types and generic args Aug 6, 2025

GuillaumeGomez mentioned this pull request Aug 6, 2025

Rollup of 15 pull requests #145020

Merged

bors merged commit d180873 into rust-lang:master Aug 7, 2025
10 checks passed

rustbot added this to the 1.91.0 milestone Aug 7, 2025


		let span = lo_attr.to(self.prev_token.span);

		if self.token.is_ident() {

Parser: Recover from attributes applied to types and generic args #144195

Parser: Recover from attributes applied to types and generic args #144195

Uh oh!

Conversation

Kivooeo commented Jul 19, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

compiler-errors Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

Kivooeo Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

compiler-errors Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

Kivooeo Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

Kivooeo Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

compiler-errors Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

compiler-errors Jul 20, 2025

Choose a reason for hiding this comment

Uh oh!

compiler-errors commented Jul 20, 2025

Uh oh!

This comment has been minimized.

Uh oh!

Kivooeo commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kivooeo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Kivooeo commented Jul 29, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kivooeo commented Aug 1, 2025

Uh oh!

fmease left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fmease Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Aug 5, 2025

Uh oh!

Kivooeo commented Aug 5, 2025

Uh oh!

Kivooeo commented Aug 5, 2025

Uh oh!

Kivooeo commented Jul 19, 2025 •

edited by rustbot

Loading

Kivooeo commented Jul 21, 2025 •

edited

Loading

fmease Aug 4, 2025 •

edited

Loading