stabilize feature(cfg_target_has_atomic_equal_alignment)

[WaffleLapkin]

See stabilization report: #93822 (comment)
cc @joshtriplett

[rustbot]

r? @mati865

rustbot has assigned @mati865.
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 12 candidates

[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 #155175) made this pull request unmergeable. Please resolve the merge conflicts.

[traviscross]

In the meeting today, we talked a bit about the name. Framing it as "target has {property}" seems right, especially in light of the existing target_has_atomic. But the word "equal" here is a bit unfortunate — one wonders, "equal to what?"

This cfg is testing that align_of::<Atomic<T>>() == align_of::<T>(). I.e., that the alignment of the atomic for some type T is the inner alignment — the alignment of the inner type.

What about target_has_atomic_inner_alignment?

[steffahn]

One potential naming concern with cfg(target_has_atomic_equal_alignment="N") is that reading aloud something like target_has_atomic="32" can already read out aloud as something like “target has atomic equal[s] thirty-two”, so there’s potential confusion in adding the word “equal” in that same position where an ”equals“ sign appears for a different (related) cfg flag.

When looking for possible other names, it also makes sense to keep in mind that this flag is going to be used with a ="N"-kind of suffix (or ="8"/="16"/="32"/="64"/="ptr") indicating which atomic size we’re talking about.

[steffahn]

Types like u8, u16… etc make up a majority of “primitive” types. See also std::primitive. So I’ve been thinking reference to primitive could help answer the question of “what is it supposed to be equal to?”

In the space of “names starting with target_has_atomic_”, I’m able to come up with things like the following.

• #[cfg(target_has_atomic_alignment_matching_primitive="32")]
• #[cfg(target_has_atomic_aligned_like_primitive="32")]
• #[cfg(target_has_atomic_primitive_align="32")]

[WaffleLapkin]

Out of the proposals above I like #[cfg(target_has_atomic_primitive_align="32")] the most (with close second being #[cfg(target_has_atomic_aligned_like_primitive="32")]). What would be the next step, should I re-nominate this to check if T-lang would be okay with that (or other) name(s), or?..

[traviscross]

It's still nominated. We'll pick it back up to discuss.