Add #[repr(transparent)] to Atomic* types #52149
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
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.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @shepmaster (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ rollup
Note that |
|
📌 Commit e769dec has been approved by |
bors
added
S-waiting-on-bors
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).
bors
added a commit
that referenced
this pull request
Jul 10, 2018
Rollup of 7 pull requests Successful merges: - #51612 (NLL: fix E0594 "change to mutable ref" suggestion) - #51722 (Updated RELEASES for 1.28.0) - #52064 (Clarifying how the alignment of the struct works) - #52149 (Add #[repr(transparent)] to Atomic* types) - #52151 (Trait impl settings) - #52171 (Correct some codegen stats counter inconsistencies) - #52195 (rustc: Avoid /tmp/ in graphviz writing) Failed merges: - #52164 (use proper footnote syntax for references) r? @ghost
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Sep 5, 2018
Added in rust-lang#52149 the discussion in rust-lang#53514 is showing how we may not want to actually add this attribute to the atomic types. While we continue to debate rust-lang#53514 this commit reverts the addition of the `transparent` attribute before it hits stable.
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Sep 5, 2018
Added in rust-lang#52149 the discussion in rust-lang#53514 is showing how we may not want to actually add this attribute to the atomic types. While we continue to debate rust-lang#53514 this commit reverts the addition of the `transparent` attribute. This should be a more conservative route which leaves us the ability to tweak this in the future but in the meantime allows us to continue discussion as well.
bors
added a commit
that referenced
this pull request
Sep 6, 2018
…r=nikomatsakis [beta]: Remove `#[repr(transparent)]` from atomics Added in #52149 the discussion in #53514 is showing how we may not want to actually add this attribute to the atomic types. While we continue to debate #53514 this commit reverts the addition of the `transparent` attribute before it hits stable.
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Sep 7, 2018
…t-atomics-master, r=sfackler Remove `#[repr(transparent)]` from atomics Added in rust-lang#52149 the discussion in rust-lang#53514 is showing how we may not want to actually add this attribute to the atomic types. While we continue to debate rust-lang#53514 this commit reverts the addition of the `transparent` attribute. This should be a more conservative route which leaves us the ability to tweak this in the future but in the meantime allows us to continue discussion as well.
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.
This allows them to be used in
#[repr(C)]structs without warnings. Since rust-lang/rfcs#1649 and #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 #51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).