refactor: shrink check_attr by moving attribute checks to parsers

[herbenderbler]

refactor: shrink check_attr by moving attribute checks into rustc_attr_parsing

Part of #153101.

Problem

compiler/rustc_passes/src/check_attr.rs accumulates a large amount of attribute validation logic. Much of that logic is really about what an attribute means on a particular syntactic target, but it historically lived next to diagnostic emission in the pass, which makes the attribute pipeline harder to follow and duplicates concepts that already live in rustc_attr_parsing.

Issue #153101 tracks shrinking check_attr and moving checks as far toward parsing as information allows. Many rules cannot run during raw attribute parsing because they need HIR / target context (e.g. “is this a trait impl?”, “is this expression a loop?”). This PR takes a concrete step in that direction without pulling rustc_middle into the attribute parser crate.

What we implemented

1. late_validation (compiler/rustc_attr_parsing/src/late_validation.rs)

New module with:

• LateValidationContext — Plain data built in check_attr from TyCtxt / HIR: Target, parent_is_trait_impl, optional expression context (loop vs break), trait-impl constness / impl_of_trait, foreign mod ABI, decl-macro flag for macro_export, etc.
• Validators that return Option<…> (or small enums) describing what is wrong, without emitting diagnostics:
  • #[deprecated] where it has no effect (trait impl members)
  • #[loop_match], #[const_continue] on the wrong expression kind
  • #[link] (foreign mod + not extern "Rust")
  • #[macro_export] on decl macros
  • Diagnostic attributes: do_not_recommend, on_unimplemented (placement), on_const, on_move (placement)
  • for_each_unknown_diagnostic_format_param — shared walk over Directive format parameters vs non-lifetime type parameters (used for on_unimplemented and on_move)

The pass check_attr remains responsible for emitting lints/errors via rustc_passes::errors and existing lint machinery; it only calls into late_validation for the predicate.

2. #[custom_mir] (compiler/rustc_attr_parsing/src/attributes/prototype.rs)

Dialect/phase compatibility and “phase without dialect” are validated in CustomMirParser via a dedicated check_custom_mir helper (same shape as the standalone parser work in #154126: failed flag + session_diagnostics). AttributeKind::CustomMir keeps optional dialect/phase with spans.

Corresponding diagnostics were removed from rustc_passes::errors and live in rustc_attr_parsing::session_diagnostics instead.

3. check_attr cleanup (compiler/rustc_passes/src/check_attr.rs)

• Builds LateValidationContext once per attribute walk and dispatches to the validators above.
• generics_has_type_param_named — small local helper for diagnostic format-parameter checking (shared by on_unimplemented / on_move arms).
• CustomMir arm is a no-op beyond a comment (validation is in the parser).

4. Small HIR doc tweak

• Directive::visit_params in compiler/rustc_hir/src/attrs/diagnostic.rs now points callers at late_validation::for_each_unknown_diagnostic_format_param for the post-HIR check.

Why this design

• Separation of concerns: Predicate logic colocated with attribute parsing in rustc_attr_parsing; rustc_passes keeps tcx/HIR wiring and user-facing diagnostics.
• Dependency layering: late_validation avoids rustc_middle / typeck; only rustc_hir + rustc_span (and Directive for format-parameter validation).
• Honest about limits: Module docs note that the long-term direction in Reduce the size of check_attrs.rs and move as much as possible into the attribute parsers. #153101 is to feed target context into parsing where possible; this module is an interim home for rules that still require a built HIR.

This matches reviewer feedback that we should not pretend check_attr is “done” when logic merely moves crates—it documents the staged approach and keeps validation code in the attribute stack.

Tests

No new tests/ files were added in this PR. Behavior is covered by existing UI / compiler tests (e.g. diagnostic namespace, custom_mir, attribute lints).

Local verification (recommended before merge):

./x.py check compiler/rustc_hir compiler/rustc_attr_parsing compiler/rustc_passes
./x.py test tidy
./x.py test tests/ui/diagnostic_namespace

Documentation

• Rustdoc on late_validation (purpose, LateValidationContext, link to Reduce the size of check_attrs.rs and move as much as possible into the attribute parsers. #153101, note on future target-aware parsing).
• Comment on CustomMir handling in check_attr.
• Directive::visit_params rustdoc cross-reference as above.

---

Rebase note

This branch was rebased onto rust-lang/rust main at 86c839ffb36. If main advances (e.g. after #154126 lands), run:

git fetch https://github.com/rust-lang/rust.git main
git rebase FETCH_HEAD   # or: git rebase rust-lang/main

If #154126 merges first, expect at most a small conflict or redundancy check in prototype.rs around check_custom_mir—the intent is a single shared implementation pattern.

[rustbot]

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

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 13 candidates

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[JonathanBrouwer]

In the future, it would be nice if you could coordinate your ideas in the issue thread or on zulip before making a PR :)

[herbenderbler]

In the future, it would be nice if you could coordinate your ideas in the issue thread or on zulip before making a PR :)

My apologies, this is my first attempt at landing a PR here 😬

[rustbot]

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

[oli-obk]

Hey!

It looks like you initially had a PR description you wrote yourself, which you then turned into a very long AI generated description. There's also some hints you did the same with the code.

Please write descriptions yourself, AI is way too bloaty, redundant and we're totally good with your original style.

While the rust project hasn't figured out a stance on AI code yet, everyone agrees that reviewers definitely should not be a reviewer of the raw AI output.

I'm going ahead and close this as I think it's not in a recoverable state.

I personally (and as stated this is something the project is actively discussing to find a policy on) would strongly discourage you from using AI at all until you're an established contributor (not saying you should use it then, but right now you don't have the experience to judge the AI output, so our reviewers are essentially just using the AI with you as the intermediary).