Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

Closed
alexcrichton opened this issue Apr 14, 2016 · 138 comments · Fixed by #57425 or #94040
Closed

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

alexcrichton opened this issue Apr 14, 2016 · 138 comments · Fixed by #57425 or #94040
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. I-lang-nominated Nominated for discussion during a lang team meeting. S-tracking-ready-to-stabilize Status: This is ready to stabilize; it may need a stabilization report and a PR T-lang Relevant to the language team, which will review and decide on the PR/issue.
Milestone

Comments

@alexcrichton
Copy link
Member

Tracking rust-lang/rfcs#1543

@alexcrichton alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 14, 2016
bors added a commit that referenced this issue May 9, 2016
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 alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Jun 21, 2016
@sfackler
Copy link
Member

sfackler commented Sep 7, 2016

This is still blocked on some reasonable way to talk about platform-specificity in a more granular way than what we currently support.

@Manishearth
Copy link
Member

Is there any reason why AtomicU32 would be hard to stabilize? We need a way to store multi-word bitflags in an atomic thingy. AtomicUsize won't work here since it's too large on 64 bit.

@sfackler
Copy link
Member

sfackler commented Oct 5, 2016

What do you mean by "too large"?

@Manishearth
Copy link
Member

Manishearth commented Oct 5, 2016

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 u32, not something larger on 64-bit.

I guess I could cfg() it and abstract over it. That solves the first problem but not the second.

@nagisa
Copy link
Member

nagisa commented Oct 5, 2016

@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 target_has_atomic="32" in your code.

@Manishearth
Copy link
Member

16-bit-usize targets would give you 16 bit atomic width.

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)

@Manishearth
Copy link
Member

What do I have to do to get these stabilized?

Any answer on this? cc @alexcrichton

The rfc looks like it's been completely implemented. IMO stabilizing it with target_has_atomic is fine, and we can add further granularity if we need in new rfcs.

@alexcrichton
Copy link
Member Author

@Manishearth state hasn't changed from before. The libs team is essentially waiting for a conclusion on the scenarios story before stabilizing.

@Manishearth
Copy link
Member

Manishearth commented Dec 16, 2016

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.

@Manishearth
Copy link
Member

(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.)

@archshift
Copy link
Contributor

Has there been any progress on this since?

@bholley
Copy link
Contributor

bholley commented Feb 4, 2017

Just FYI: Per [1], Gecko's Quantum CSS project is no longer blocked on this issue.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1336646

@nagisa
Copy link
Member

nagisa commented May 7, 2017

We can stabilise AtomicU8 and AtomicI8 the same way we have stabilised AtomicBool – by using Atomic{I/U}Size operations everywhere.

@bors bors closed this as completed in 930fc4f Feb 17, 2022
@thomcc
Copy link
Member

thomcc commented Feb 17, 2022

Should a tracking issue be filed for cfg(target_has_atomic_load_store) now that it's unstable?

@Mark-Simulacrum
Copy link
Member

I filed one - #94039. Forgot to actually link it from here though.

@ehuss
Copy link
Contributor

ehuss commented Feb 17, 2022

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 cfg(target_has_atomic="...")?

@tamird
Copy link
Contributor

tamird commented Jun 23, 2022

This issue is closed, but several unstable annotations still refer to it:

#[cfg(target_has_atomic_load_store = "128")]
atomic_int! {
cfg(target_has_atomic = "128"),
cfg(target_has_atomic_equal_alignment = "128"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
rustc_const_stable(feature = "const_integer_atomics", since = "1.34.0"),
unstable(feature = "integer_atomics", issue = "32976"),
cfg_attr(not(test), rustc_diagnostic_item = "AtomicI128"),
"i128",
"#![feature(integer_atomics)]\n\n",
atomic_min, atomic_max,
16,
"AtomicI128::new(0)",
i128 AtomicI128 ATOMIC_I128_INIT
}
#[cfg(target_has_atomic_load_store = "128")]
atomic_int! {
cfg(target_has_atomic = "128"),
cfg(target_has_atomic_equal_alignment = "128"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
unstable(feature = "integer_atomics", issue = "32976"),
rustc_const_stable(feature = "const_integer_atomics", since = "1.34.0"),
unstable(feature = "integer_atomics", issue = "32976"),
cfg_attr(not(test), rustc_diagnostic_item = "AtomicU128"),
"u128",
"#![feature(integer_atomics)]\n\n",
atomic_umin, atomic_umax,
16,
"AtomicU128::new(0)",
u128 AtomicU128 ATOMIC_U128_INIT
}

Is there another issue that should be linked there?

@RalfJung
Copy link
Member

Good catch! integer_atomics needs a tracking issue. This one here seems to have been used for that (judging from #56753) but its title doesn't even reflect that... so it's probably best to open a new tracking issue and adjust the annotations.

Dylan-DPC pushed a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022
…fJung

Update integer_atomics tracking issue

Updates rust-lang#32976.
Updates rust-lang#99069.

r? `@RalfJung`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022
…fJung

Update integer_atomics tracking issue

Updates rust-lang#32976.
Updates rust-lang#99069.

r? ``@RalfJung``
JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jul 26, 2022
JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jul 26, 2022
…fJung

Update integer_atomics tracking issue

Updates rust-lang#32976.
Updates rust-lang#99069.

r? ``@RalfJung``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 3, 2022
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).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 3, 2022
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).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 3, 2022
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).
thomcc pushed a commit to tcdi/postgrestd that referenced this issue Feb 10, 2023
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).
@juntyr
Copy link
Contributor

juntyr commented Sep 30, 2024

What is the current status of #[cfg(target_has_atomic = ...)]? Are there outstanding design or implementation concerns? Is stabilisation only waiting for someone to pick up the work?

@Amanieu
Copy link
Member

Amanieu commented Oct 1, 2024

target_has_atomic has been stable since 1.60.

@juntyr
Copy link
Contributor

juntyr commented Oct 1, 2024

target_has_atomic has been stable since 1.60.

Whoops, my mistake, I meant [cfg(target_has_atomic_load_store = ...)] but was caught by #94039 (comment) where the feature is still named cfg_target_has_atomic and directs to here - thanks for your help and sorry for the noise

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. I-lang-nominated Nominated for discussion during a lang team meeting. S-tracking-ready-to-stabilize Status: This is ready to stabilize; it may need a stabilization report and a PR T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet