Rewrite the #[repr] attribute parser

[JonathanBrouwer]

The #[repr] attribute parser was one of the first attribute parsers we made, and didn't use a lot of the awesome infra we have nowadays yet, so in preparation for a new approach I'm trying for #156569 I decided to clean it up.

This PR should have no observable effect other than improved diagnostic messages.

r? @mejrs

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

[JonathanBrouwer]

One thing that still annoys me is that in a lot of attribute parsers have these match statements, and then we need to list all branches of the match statement again for the expected_specific_argument error

View changes since the review

[mejrs]

I'd like a solution where these symbols are only listed once.

Maybe make an array of [(Symbol, constructor); _] (or maybe [(Symbol, checker, constructor); _]) and if you don't find the symbol in the array, do something like array.iter().map(|x|x.0).collect() and pass that to expected_specific_argument.

See

rust/compiler/rustc_resolve/src/macros.rs

Line 716 in 6368fd5

const DIAGNOSTIC_ATTRIBUTES: &[(Symbol, Option<Symbol>)] = &[

for inspiration.

[JonathanBrouwer]

(let's leave this for a separate PR tho, since this affects more places that I'd like to fix at the same time)

[mejrs]

I'll continue reviewing tomorrow, just some comments so far.

The error code for the cfg_select errors are (and were) unfortunate. I will file an issue for that later.

View changes since this review

[mejrs]

I'd like a solution where these symbols are only listed once.

Maybe make an array of [(Symbol, constructor); _] (or maybe [(Symbol, checker, constructor); _]) and if you don't find the symbol in the array, do something like array.iter().map(|x|x.0).collect() and pass that to expected_specific_argument.

See

rust/compiler/rustc_resolve/src/macros.rs

Line 716 in 6368fd5

const DIAGNOSTIC_ATTRIBUTES: &[(Symbol, Option<Symbol>)] = &[

for inspiration.

[theemathas]

Does this conflict with #157036 ?

[JonathanBrouwer]

Does this conflict with #157036 ?

Not really. The code will have merge conflicts, but that shouldn't be too severe. This PR doesn't have any observable changes other than changes in diagnostics, I'm leaving those for #157036