Add a lint helper attribute namespace

[mejrs]

(and also port over three rustc lint attributes, as proof of concept)

Note

The below discussion assumes #162597 has been merged.

That PR implements an ambiguity error if #[tool::attr] can refer to either an attribute macro or a tool attribute. In particular this means adding a new built-in tool is a breaking change, if not done over an edition.

This PR implements parsing for the lint tool namespace (#[lint::attribute]) but doesn't add it as a builtin tool, so #![register_tool(lint)] is also required to use it. It raises an error on an unknown attribute within that namespace.

The primary motivations for creating this namespace are:

• creating a place for attributes like trivial_field_reads (expanding #[rustc_trivial_field_reads] to more targets, place on Derive and Clone #160666) and c_buffer_length (Add c_buffer_length diagnostic attribute #162565) to live, as these IMO do not belong in the diagnostic namespace.
• make it easier to unstably land lints and lint helper attributes, as these currently suffer from the "any new built-in attribute is a breaking change" problem.
• implementing (part of) Tracking issue for MCP 1021: Implement a naming convention for lint/diagnostic-only rustc_ attrs #160808

What is a "lint helper"

Attributes that change how or if a lint is emitted. Think of many of the internal attributes like #[rustc_as_ptr] , #[rustc_pass_by_value] etc. Other examples are #[deprecated] and #[must_not_suspend]. Even clippy has such a thing: #[clippy::format_args].

On breaking changes

This doesn't add lint as a built-in tool (like diagnostic, rustfmt, clippy etc are) so this pr is not a breaking change. The breaking changes are opt-in by using #![register_tool(lint)] in the crate root which is unstable at this time.

The way this PR is implemented means that, even if users could use #![register_tool(lint)] stably, they cannot stably use the namespace because an unknown attribute is an error and all valid attributes in it, at this time, are also feature gated. So there is no commitment to stability until we choose to stabilize an attribute in it.

Going forward

We can require using #![register_tool(lint)] indefinitely. It's possible to not require this this by adding lint as a builtin tool, but this (assuming #162597) breaks

#[lint::as_ptr]
struct Foo;

mod lint {
    // On stable rust, this could be a re-exported proc macro
    pub macro as_ptr {
        attr() { $($tt:tt)* } => { $($tt)* }
    }
}

However as nobody on github does this it's probably only theoretically breaking. It's non-breaking to add it across an edition.

r? @estebank
cc @WaffleLapkin @petrochenkov

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

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

cc @rust-lang/clippy

[rustbot]

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.

[rust-bors]

☔ The latest upstream changes (presumably #163957) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[petrochenkov]

I originally self-assigned because I'd seen the word "namespace", which means something big, like type/value/macro namespaces.
But this is only adds a new "tool module" (in rustc-internal terms) like diagnostic, so it doesn't add something new to the language.