Tracking issue for #[cfg(target_has_atomic = ...)] #32976
Comments
alexcrichton
added
B-RFC-approved
Add integer atomic types Tracking issue: #32976 RFC: rust-lang/rfcs#1543 The changes to AtomicBool in the RFC are not included, they are in a separate PR (#32365).
alexcrichton
added
B-unstable
|
This is still blocked on some reasonable way to talk about platform-specificity in a more granular way than what we currently support. |
|
Is there any reason why |
|
What do you mean by "too large"? |
|
Let's say I have a 64-bit bucket of flags. I need two atomic u32s to represent it. I can't use two usizes because that's too large on 64 bit. Alternatively, let's say I have a 32-bit bucket of flags. This is on a struct where size matters. I need a I guess I could |
|
@Manishearth 16-bit-usize targets would give you 16 bit atomic width. 100% savings over 32bit systems! (and potential loss of data) There isn’t really much problem stabilising any of these IMO, but you’ll still have to CFG on |
ugh, these exist, right. What do I have to do to get these stabilized? I'm okay with the cfgs. I'm also okay with just u8 being stabilized, as long as I can pack it (not sure if this is possible with atomics) |
Any answer on this? cc @alexcrichton The rfc looks like it's been completely implemented. IMO stabilizing it with |
|
@Manishearth state hasn't changed from before. The libs team is essentially waiting for a conclusion on the scenarios story before stabilizing. |
|
That discussion has stalled. Last I checked it seemed to mostly have come to consensus on the general idea? Who are we waiting on for a conclusion here? What would the ETA on this be? How can I help? It also seems like that's mostly orthogonal to this. We can stabilize this using cfgs, and add scenarios later. They seem to be pretty compatible. |
|
(After discussing in IRC, it seems like there have been a lot of recent discussions about this, and the libs team is currently moving on pushing this forward.) |
|
Has there been any progress on this since? |
|
Just FYI: Per [1], Gecko's Quantum CSS project is no longer blocked on this issue. |
|
We can stabilise AtomicU8 and AtomicI8 the same way we have stabilised AtomicBool – by using Atomic{I/U}Size operations everywhere. |
|
We discussed this in today's @rust-lang/lang meeting. We'd like to roll back the portion of the stabilization PR that stabilized We'd also like to have documentation for |
|
I've filed rust-lang/reference#1171 to document target_has_atomic in the reference, and #94040 to destabilize load_store. |
|
Should a tracking issue be filed for |
|
I filed one - #94039. Forgot to actually link it from here though. |
|
There's a small mention at atomic.rs that says it is still unstable. Would someone be willing to rewrite that paragraph to mention using |
|
This issue is closed, but several rust/library/core/src/sync/atomic.rs Lines 2467 to 2506 in 10f4ce3 Is there another issue that should be linked there? |
|
Good catch! |
Updates rust-lang#32976. Updates rust-lang#99069.
…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? `@RalfJung`
…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``
Updates rust-lang#32976. Updates rust-lang#99069.
…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``
Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang#32976) but [not yet documented in the reference](rust-lang/reference#1171).
Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang#32976) but [not yet documented in the reference](rust-lang/reference#1171).
Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang#32976) but [not yet documented in the reference](rust-lang/reference#1171).
Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang/rust#32976) but [not yet documented in the reference](rust-lang/reference#1171).
and others
Tracking rust-lang/rfcs#1543
The text was updated successfully, but these errors were encountered: