Stabilize unions with Copy fields and no destructor
#42068
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
aidanhs
added
the
S-waiting-on-review
This was referenced May 18, 2017
|
Glad to see this becoming stable!
I am not generally a fan of backporting anything that's not crucial. |
|
ping @nikomatsakis, pinging you on IRC too! |
|
I'm waiting on this until #42083 lands. |
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
May 24, 2017
…akis Make assignments to `Copy` union fields safe This is an accompanying PR to PR rust-lang#42068 stabilizing FFI unions. This was first proposed in rust-lang#32836 (comment), see subsequent comments as well. Assignments to `Copy` union fields do not read any data from the union and are [equivalent](rust-lang#32836 (comment)) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular. It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code. cc rust-lang#32836 r? @nikomatsakis
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
May 24, 2017
…akis Make assignments to `Copy` union fields safe This is an accompanying PR to PR rust-lang#42068 stabilizing FFI unions. This was first proposed in rust-lang#32836 (comment), see subsequent comments as well. Assignments to `Copy` union fields do not read any data from the union and are [equivalent](rust-lang#32836 (comment)) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular. It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code. cc rust-lang#32836 r? @nikomatsakis
bors
added a commit
that referenced
this pull request
May 26, 2017
Make assignments to `Copy` union fields safe This is an accompanying PR to PR #42068 stabilizing FFI unions. This was first proposed in #32836 (comment), see subsequent comments as well. Assignments to `Copy` union fields do not read any data from the union and are [equivalent](#32836 (comment)) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular. It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code. cc #32836 r? @nikomatsakis
|
☔ The latest upstream changes (presumably #42083) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r=me once rebased |
nikomatsakis
added
S-waiting-on-author
|
@bors r=nikomatsakis |
|
📌 Commit 73c73e4 has been approved by |
|
⌛ Testing commit 73c73e4 with merge fc26e66... |
|
💔 Test failed - status-appveyor |
|
@bors retry
|
bors
added a commit
that referenced
this pull request
May 27, 2017
Stabilize unions with `Copy` fields and no destructor What else is needed: - [x] Documentation (rust-lang/reference#57). - [x] Making assignments to `Copy` union fields safe (#42083). - [ ] Backport? (The "stabilization decision" is from [Apr 13](#32836 (comment)), it's just this PR is late.) cc #32836 r? @nikomatsakis
|
☀️ Test successful - status-appveyor, status-travis |
5 tasks
brson
added
beta-accepted
|
Were going to try to backport. |
|
cc @rust-lang/compiler |
This was referenced May 31, 2017
|
@brson I don't strongly object, but I'm surprised you would backport. I feel like we try to keep backports to regressions or important bug fixes, and only rarely backport stabilizations -- the exception would be if some feature is hotly demanded. But otoh this seems pretty darn low risk, so no real objection. |
brson
removed
beta-accepted
|
I closed the backport. It was feeling non-trivial and there wasn't a great deal of agreement about it. |
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.
What else is needed:
Copyunion fields safe (Make assignments toCopyunion fields safe #42083).cc #32836
r? @nikomatsakis