Skip to content

document safety requirements for atomic intrinsics - #163140

Merged
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
yilin0518:fix_atomic_ops
Oct 4, 2026
Merged

rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
yilin0518:fix_atomic_ops

Conversation

@yilin0518

@yilin0518 yilin0518 commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

This PR serves as a complement to PR #162854 by adding safety docs for the remaining atomic operations. These operations pass raw pointers as arguments and are marked unsafe, so I think it is necessary to explain why they are unsafe.

For atomic_cxchg, atomic_cxchgweak, atomic_xchg, these APIs have the same process whether T is an integer or a pointer type.

For atomic_xadd, atomic_xsub, atomic_and, atomic_or, atomic_xor, these APIs correspond to different operations in core/src/sync/atomic.rs for T is an integer or a pointer type.

For atomic_max, atomic_min, atomic_umax, atomic_umin, they only process when T is an integer (signed or unsigned) type.

For atomic_nand, there doesn't exist a method in AtomicPtr<T>, so I don't link the related method.

@rustbot

rustbot commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 22, 2026
@rustbot

rustbot commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

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: libs
  • libs expanded to 12 candidates
  • Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt

Comment thread library/core/src/intrinsics/mod.rs Outdated
///
/// # Safety
///
/// This is equivalent to [Atomic::from_ptr] followed by [Atomic::compare_exchange],

@Mark-Simulacrum Mark-Simulacrum Sep 27, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to write these they should specify the full type, via something like <Atomic<T>>::from_ptr - otherwise the alignment safety requirement requires some parsing.

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to write these they should specify the full type, via something like <Atomic<T>>::from_ptr - otherwise the alignment safety requirement requires some parsing.

I did some modification about this PR. First, I replaced Atomic::from_ptr with Atomic<T>::from_ptr. I understand the requirement that should specify the full type, but it can only add a concrete type for the doc link (I chose AtomicI32 for unification).

Second, add pointer safety requirement for atomic_cxchg, atomic_cxchgweak and atomic_xchg. And for every place talking about pointer type, I use AtomicPtr<P> to denote that T is a pointer type.

Third, remove the "with ..." part and place it in the beginning.

Thank you for your feedback! If there exist some other wrong discriptions I will fix them.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to write these they should specify the full type, via something like <Atomic<T>>::from_ptr - otherwise the alignment safety requirement requires some parsing.

I did some modification about this PR. First, I replaced Atomic::from_ptr with Atomic<T>::from_ptr. I understand the requirement that should specify the full type, but it can only add a concrete type for the doc link (I chose AtomicI32 for unification).

Second, adding pointer safety requirement for atomic_cxchg, atomic_cxchgweak and atomic_xchg. And for every place talking about pointer type, I use AtomicPtr<P> to denote that T is a pointer type.

Third, removing the "with ..." part and place it in the beginning.

Thank you for your feedback! If there exist some other wrong discriptions I will fix them.

Comment thread library/core/src/intrinsics/mod.rs Outdated
///
/// This is equivalent to [Atomic::from_ptr] followed by [Atomic::compare_exchange],
/// with the returned `T` being the previous value and the returned `bool` being
/// whether the exchange was successful.

@Mark-Simulacrum Mark-Simulacrum Sep 27, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove the "with ..." part (and probably the compare_exchange part, at least from here; if you want it it should be outside the safety section). The safety requirements here are exactly the same as <Atomic<T>>::from_ptr AFAICT.

View changes since the review

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 27, 2026
@rustbot

rustbot commented Sep 27, 2026

Copy link
Copy Markdown
Collaborator

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

@yilin0518

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 28, 2026
@rust-log-analyzer

This comment has been minimized.

@Mark-Simulacrum Mark-Simulacrum left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rust-bors

rust-bors Bot commented Oct 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 99cc8cf has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 3, 2026
jhpratt added a commit to jhpratt/rust that referenced this pull request Oct 3, 2026
…imulacrum

document safety requirements for atomic intrinsics

This PR serves as a complement to PR rust-lang#162854 by adding safety docs for the remaining atomic operations. These operations pass raw pointers as arguments and are marked unsafe, so I think it is necessary to explain why they are unsafe.

For `atomic_cxchg`, `atomic_cxchgweak`, `atomic_xchg`, these APIs have the same process whether `T` is an integer or a pointer type.

For `atomic_xadd`, `atomic_xsub`, `atomic_and`, `atomic_or`, `atomic_xor`, these APIs correspond to different operations in `core/src/sync/atomic.rs` for `T` is an integer or a pointer type.

For `atomic_max`, `atomic_min`, `atomic_umax`, `atomic_umin`, they only process when `T` is an integer (signed or unsigned) type.

For `atomic_nand`, there doesn't exist a method in `AtomicPtr<T>`, so I don't link the related method.
rust-bors Bot pushed a commit that referenced this pull request Oct 4, 2026
Rollup of 18 pull requests

Successful merges:

 - #158102 (When compiling without a specified `--edition`, emit a message)
 - #162027 (std: add `fs::rename_noreplace`)
 - #162761 (Lower attributes for functions without bodies)
 - #163161 (implement FCW for `rustc_allowed_through_unstable_modules` items)
 - #163613 (Tweak the rendering of "not general enough" errors on the old trait solver)
 - #162062 (core: fix the docs of PanicInfo::location)
 - #163140 (document safety requirements for atomic intrinsics)
 - #163342 (Don't imply incorrect things about `Global` in the docs of `System`)
 - #163445 (Add safety comments for alloc::str)
 - #163503 (Mark Rc strong/weak count methods must_use)
 - #163548 (fs::set_permissions_nofollow: Android support, test cleanup)
 - #163585 ([triagebot] Create `debugger_visualizer` assign group)
 - #163597 (Add `SplitPathsRef` implementation for motor to make std build)
 - #163602 (Move media & home dirs tests to fs tests.)
 - #163667 (Finalize changes on expect messages for library/core/src/fmt/mod.rs)
 - #163682 ([rustdoc] Correctly link to (imported) enum variants with "jump to def")
 - #163683 (Fix GCC codegen backend comment in bootstrap)
 - #163703 (Move more `rustdoc-html tests` in the right location)

Failed merges:

 - #161491 (Rip out old solver coherence)
rust-bors Bot pushed a commit that referenced this pull request Oct 4, 2026
Rollup of 18 pull requests

Successful merges:

 - #158102 (When compiling without a specified `--edition`, emit a message)
 - #162761 (Lower attributes for functions without bodies)
 - #163161 (implement FCW for `rustc_allowed_through_unstable_modules` items)
 - #163613 (Tweak the rendering of "not general enough" errors on the old trait solver)
 - #162062 (core: fix the docs of PanicInfo::location)
 - #163140 (document safety requirements for atomic intrinsics)
 - #163342 (Don't imply incorrect things about `Global` in the docs of `System`)
 - #163445 (Add safety comments for alloc::str)
 - #163503 (Mark Rc strong/weak count methods must_use)
 - #163548 (fs::set_permissions_nofollow: Android support, test cleanup)
 - #163585 ([triagebot] Create `debugger_visualizer` assign group)
 - #163597 (Add `SplitPathsRef` implementation for motor to make std build)
 - #163602 (Move media & home dirs tests to fs tests.)
 - #163667 (Finalize changes on expect messages for library/core/src/fmt/mod.rs)
 - #163682 ([rustdoc] Correctly link to (imported) enum variants with "jump to def")
 - #163683 (Fix GCC codegen backend comment in bootstrap)
 - #163703 (Move more `rustdoc-html tests` in the right location)
 - #163725 (some crashes fixed with next-solver)

Failed merges:

 - #161491 (Rip out old solver coherence)
@rust-bors
rust-bors Bot merged commit cab3473 into rust-lang:main Oct 4, 2026
13 checks passed
@rustbot rustbot added this to the 1.101.0 milestone Oct 4, 2026
rust-bors Bot pushed a commit that referenced this pull request Oct 4, 2026
Rollup merge of #163140 - yilin0518:fix_atomic_ops, r=Mark-Simulacrum

document safety requirements for atomic intrinsics

This PR serves as a complement to PR #162854 by adding safety docs for the remaining atomic operations. These operations pass raw pointers as arguments and are marked unsafe, so I think it is necessary to explain why they are unsafe.

For `atomic_cxchg`, `atomic_cxchgweak`, `atomic_xchg`, these APIs have the same process whether `T` is an integer or a pointer type.

For `atomic_xadd`, `atomic_xsub`, `atomic_and`, `atomic_or`, `atomic_xor`, these APIs correspond to different operations in `core/src/sync/atomic.rs` for `T` is an integer or a pointer type.

For `atomic_max`, `atomic_min`, `atomic_umax`, `atomic_umin`, they only process when `T` is an integer (signed or unsigned) type.

For `atomic_nand`, there doesn't exist a method in `AtomicPtr<T>`, so I don't link the related method.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants