Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred to diagnostic attributes.

cc @mejrs

Some more details: there is tremendous inconsistency in how attributes are referred to in error messages. In error lines, we see all of these (and possibly more) in different messages:

• the #[foo] attribute is...
• the foo attribute is...
• attribute foo is...
• foo is...
• foo is...

Furthermore, carets sometimes point at the full attribute (including the #[/#![/] delimiters), sometimes at just the "inner" (everything within the delimiters), and sometimes at something more specific such as the attribute path. Examples:

// The full attribute including delimiters.
error[E0658]: the `#[coroutine]` attribute is an experimental feature
   |
LL |     let _ = #[coroutine] || yield true;
   |             ^^^^^^^^^^^^

// Just the attribute path.
error: cannot find attribute `lint` in this scope
   |
LL | #[lint("this is an example message", code = E0123)]
   |   ^^^^

Often the error line says something that doesn't match the actual source code pointed to by the carets. Examples:

// Error line omits attribute arguments.
error: the `#![crate_name]` attribute can only be used at the crate root
   |
LL | #![crate_name = "bar"]
   | ^^^^^^^^^^^^^^^^^^^^^^

// Error line omits the `unsafe(..)`.
error: the `#[proc_macro]` attribute is only usable with crates of the `proc-macro` crate type
   |
LL | #[unsafe(proc_macro)]                             
   | ^^^^^^^^^^^^^^^^^^^^^  

// Error line omits the `cfg_attr(broken, ..)`.
error[E0658]: the `#[no_core]` attribute is an experimental feature
   |
LL | #![cfg_attr(broken, no_core)]                     
   |                     ^^^^^^^  

// Error line omits the `!`.
error[E0658]: the `#[needs_panic_runtime]` attribute is an experimental feature
   |
LL | #![needs_panic_runtime]
   | ^^^^^^^^^^^^^^^^^^^^^^^

I propose the following:

• As much as possible, use only the backticked attribute path in error lines.
  • The form "the foo attribute" should be used whenever it makes sense.
  • Some exceptions, e.g. "cannot find attribute foo in this scope" because that message is used for things other than attributes.
  • This avoids writing text that doesn't appear in the code, e.g. avoids inconsistencies with omitted arguments and unsafe and cfg_attr.
• As much as possible, highlight just the attribute path with carets.
  • This is the most specific highlighting, and matches with what's named in the error line.
  • But when the error is in arguments to an attribute, the carets will still include the arguments.

This covers the vast majority of cases. There will be some exceptions, e.g. when suggesting what to write:

= help: consider adding a `#[repr(C)]`, `#[repr(transparent)]`, or integer `#[repr(...)]` attribute to this enum

or when the delimiters are significant:

error: an inner attribute is not permitted in this context
   | 
LL |     let a = #![allow(warnings)] (1, 2);
   |             ^^^^^^^^^^^^^^^^^^^
   |                                                                    
   = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files                
   = note: outer attributes, like `#[test]`, annotate the item following them

These cases are rare.

cc @petrochenkov

The form "the foo attribute" should be used whenever it makes sense.

In case it's relevant: the Rust reference mostly uses this form, e.g. "the test attribute", "the derive attribute". (Although it also sometimes uses e.g. "the #[expect(C)] attribute", "the #[diagnostic] attribute".)

Can you also add this to the diagnostic style guide?

Happy to, if/when this gets approval from reviewers :)

rustc-dev-guide is developed in its own repository. If possible, consider making this change to rust-lang/rustc-dev-guide instead.

cc @BoxyUwU, @tshepang

I added an extra commit with a style guide addition.

@bors r=estebank

📌 Commit cd8a779 has been approved by estebank

It is now in the queue for this repository.