Include AtomicU128/AtomicI128 in docs for any target

[pluiee]

Fixes #130474

This is my first contribution, so I'll try to be as descriptive as possible of my process and thoughts.

• Environment: Cross compiled in Macbook M1 Air
• Testing: I replicated the bug and checked fixes with ./x doc library/core --target x86_64-unknown-linux-gnu (building the std doc didn't seem to apply my local changes so I used the core doc) Check the screenshots below.
• Diffs: I added #[cfg(any(...,doc))] to all required structs and implementations so the types would compile. Applyingtarget_has_atomic_equal_alignment part wasn't explicitly necessary, but adding it reveals the whole methods (specifically from_mut and from_mut_slice).
• Thoughts: Also wondered if additional messages should be written to notify the available targets, but the documentation already included the following sentence that seemed enough.
  • Note: This type is only available on platforms that support atomic loads and stores of u128/i128

[Before]

[After]

---

After the first work, doc tests were failing in CI, so I added #[$cfg_cas] to all methods in the atomic_int macro to cover them. But I'm not really sure if all these changes are necessary (and appropriate).
This also has a side-effect of stating "Available on target_has_atomic=128 only." for all methods with the attribute. Also not sure if this is a good behavior..

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: @scottmcm, libs
• @scottmcm, libs expanded to 7 candidates
• Random selection from Mark-Simulacrum, jhpratt, scottmcm

[Mark-Simulacrum]

After the first work, doc tests were failing in CI, so I added #[$cfg_cas] to all methods in the atomic_int macro to cover them. But I'm not really sure if all these changes are necessary (and appropriate).

Hm, can you say more about the failure you were seeing? I suspect we were trying to run doc tests for AtomicU128 which indeed doesn't make sense if the target doesn't have u128 atomics... but I'd have expected that if the cfg is needed to avoid that we would have already hit the same problem for platforms that don't have the full set of atomic types.

Maybe only a subset of the tests were failing?

[pluiee]

@Mark-Simulacrum

The failure mentioned in the previous PR is exactly the behavior I saw after adding #[cfg(any(..., doc))]. It appears to be a general compilation issue with the doctests rather than isolated test failures.

but I'd have expected that if the cfg is needed to avoid that we would have already hit the same problem for platforms that don't have the full set of atomic types.

As far as I understand, this is a unique case where we want to expose a type in the docs that isn't actually supported, because the official docs are built for a specific target (x86_64-unknown-linux-gnu). Previously, if a platform didn't support certain atomics, the type would simply be gated out, so I'm a bit confused as to why you'd expect this problem to occur even without the changes in this PR.
Or are there prior cases where types were exposed only in the docs without requiring this kind of extra handling for doctests?

[rust-bors]

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