Add #[repr(transparent)] to some libcore types #51395
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SimonSapin
added
A-attributes
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Let’s get libs and lang team sign off for libcore types: @rfcbot fcp merge Are there more types that belong on this list? |
|
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:
No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
This was referenced Jun 6, 2018
SimonSapin
force-pushed
the
repr-transparent
branch
from
27afcec to
2b29108
Compare
|
Adding it to the atomic types would be very helpful, since it would allow them to be used in |
|
Do we guarantee the size of atomic sizes, btw? |
|
@willmo Good point, added. @eddyb The current implementation has the size of each atomic type be what the name suggests, and makes some of them not available depending on the |
|
IIRC, C++ will use mutexes and/or wider integers to simulate support when the target doesn't support the atomic's width. Are we sure that we don't intend to ever do that as well? Because giving guarantees about the size of an atomic would make that impossible, unless I am missing something. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
sfackler
reviewed
Jun 7, 2018
src/libcore/sync/atomic.rs
Outdated
| @@ -124,6 +124,7 @@ pub fn spin_loop_hint() { | |||
| /// [`bool`]: ../../../std/primitive.bool.html | |||
| #[cfg(target_has_atomic = "8")] | |||
| #[stable(feature = "rust1", since = "1.0.0")] | |||
| #[repr(transparent)] | |||
| pub struct AtomicBool { | |||
There was a problem hiding this comment.
This is a bit iffy I think. Presumably you'd expect it to be FFI compatible with a bool, not a u8, right?
There was a problem hiding this comment.
Do we not have AtomicBool on platforms without u8 atomics? I could've sworn we were using usize before, which would've made the AtomicBool change a breaking one - assuming there is a platform where usize atomics exist but not byte ones.
Also, why is this not wrapping AtomicU8? Seems like the code would be safer/cleaner that way.
There was a problem hiding this comment.
The type has a #[cfg(target_has_atomic = "8")]. It should start wrapping AtomicU8, but it existed way before that type did.
|
@fitzgen There is the fallback of a single static mutex that isn't stored in the type, though that obviously has its own downsides! We've historically felt that we didn't want to do the mutex fallback, and instead have people opt into that via some library that wrapped the atomic types. It has been a while so it would be good to make sure everyone's on board with that approach though. |
|
In C++ std::atomic<bool> is not necessarily the size of a bool. |
|
@sfackler What if we did the "mutex" thing but through a one-byte spinning "rw-lock" with no OS handoff for sleeping? It would work for bare-metal usecases just as well, assuming the types it's used with are small enough to not melt one core while another operates on the data. |
|
@eddyb that wouldn't be "transparent". |
|
I would argue that the atomic types should have the appropriate native size, and not exist if that type can't be atomic on the target platform. If we want a type based on a mutex, that should use a different structure that can embed some form of synchronization. |
SimonSapin
force-pushed
the
repr-transparent
branch
from
b49161c to
2b29108
Compare
|
Alright, since atomic types being |
SimonSapin
force-pushed
the
repr-transparent
branch
from
2b29108 to
3ef6c15
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
|
@bors r+ |
|
📌 Commit 530d7bc has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 3, 2018
Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique` CC #43036
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Flaky network? @bors retry |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 4, 2018
Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique` CC #43036
|
☀️ Test successful - status-appveyor, status-travis |
rfcbot
added
finished-final-comment-period
|
@SimonSapin re:
Done: #52149 :-) |
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
Jul 10, 2018
Add #[repr(transparent)] to Atomic* types This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit. This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Jul 10, 2018
Add #[repr(transparent)] to Atomic* types This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit. This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
UnsafeCellCellNonZero*NonNullUniqueCC #43036