Mitigate #[align] name resolution ambiguity regression with a rename

[jieyouxu]

Mitigates beta regression #143834 after a beta backport.

Background on the beta regression

The name resolution regression arises due to #142507 adding a new feature-gated built-in attribute named #[align]. However, unfortunately even introducing new feature-gated unstable built-in attributes can break user code such as

macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous

Mitigation approach

This PR renames #[align] to #[xxxxx_temp_mitigation_rename_of_align_xxxxx] to mitigate the beta regression by:

1. Undoing the introduction of a new built-in attribute with a common name, i.e. #[align].
2. Using a long, very uncommon placeholder attribute name to minimize probability of colliding with user defined macros or derive proc-macro attributes of the same name. This can technically break user code who defines a macro_rules! macro or proc-macro attribute named xxxxx_temp_mitigation_rename_of_align_xxxxx, but I consider that practically sufficiently unlikely.

This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in #t-lang > namespacing macro attrs to reduce conflicts with new adds.

Alternative mitigation options

Various mitigation options were considered during the compiler triage meeting, and those consideration are partly reproduced here:

• Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
• Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
• Rename the attribute to something extremely unlikely to conflict with user code seems like the most pragmatic short-term mitigation and the meeting consensus was to proceed with that. The thinking was:
  • This alleviates the time pressure to address this regression, or for lang to have to rush an FCP for some new name that can still break user code.
  • This avoids backing out a whole implementation.

Review advice

This PR is best reviewed commit-by-commit.

• Commit 1 adds a test tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs which demonstrates the current name resolution regression re. align. This test fails against current master.
• Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs to change from fail (nameres regression) to pass.

This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
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

[rustbot]

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

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

cc @jdonszelmann

The Miri subtree was changed

cc @rust-lang/miri

[compiler-errors]

We reserve rustc_ attrs, should we just give it a name w/ rustc_ as a prefix rather than such a random name? 😸

[jieyouxu]

Remark: intentional to minimize diff lines

[jieyouxu]

We reserve rustc_ attrs, should we just give it a name w/ rustc_ as a prefix rather than such a random name? 😸

That would require feature(rustc_attrs) gate too, right? I suppose that might be okay? I don't recall exactly if rustc_* attributes have other name resolution differences 🤔

I could give that a try when I wake up.

[compiler-errors]

That would require feature(rustc_attrs) gate too, right?

For the tests that utilize the feature, yes, but presumably nobody should be using this feature anyways with this placeholder name.

There's no special resolver behavior for rustc_ attrs afaict, it's just a better sign that "this is a reserved name".

[jieyouxu]

Yeah good point. I'll make that change.
@rustbot author

[folkertdev]

btw this feature is actually used in the wild, and has worked reliably for years. We're allowed to break nightly features of course, but yeah, the rustc_align approach seems better than such a long/weird name.