Parser: Recover from attributes applied to types and generic args

[Kivooeo]

r? compiler

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

fixes #135017
fixes #144132

[compiler-errors]

r? compiler-errors

[Kivooeo]

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`.

[Kivooeo]

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

[Kivooeo]

@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.

[Kivooeo]

@rustbot ready

[fmease]

Final stretch, after that I'll approve.

[rustbot]

⚠️ 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]

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]

@rustbot ready

[fmease]

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

[bors]

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

It is now in the queue for this repository.