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

do not apply DerefMut on union field #75584

Merged
merged 4 commits into from
Sep 5, 2020
Merged

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Aug 16, 2020

This implements the part of RFC 2514 about DerefMut. Unlike described in the RFC, we only apply this warning specifically when doing DerefMut of a ManuallyDrop field; that is really the case we are worried about here.

@matthewjasper suggested I patch convert_place_derefs_to_mutable and convert_place_op_to_mutable for this, but I could not find anything to do in convert_place_op_to_mutable and this is sufficient to make the test pass. However, maybe there are some other cases this misses? I have no familiarity with this code.

This is a breaking change in theory, if someone used ManuallyDrop<T> in a union field and relied on automatic DerefMut. But on stable this means T: Copy, so the ManuallyDrop is rather pointless.

Cc #55149

@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 16, 2020
--> $DIR/union-deref.rs:18:14
|
LL | unsafe { u.f.0.0 = Vec::new() };
| ^^^^^^^
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The span for this is slightly wrong, I'd expect it to only cover u.f.0. I don't know how this is happening, since the span is right above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would guess this has to do with the special handling of multiple tuple field accesses in a row. Perhaps 0.0 is a float token.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know there was such special handling.^^ So this would be a problem elsewhere, in the code that sets up the span for these places?

@petrochenkov
Copy link
Contributor

r? @matthewjasper

Copy link
Contributor

@matthewjasper matthewjasper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good.

src/test/ui/union/union-deref.rs Show resolved Hide resolved
@bors

This comment has been minimized.

@RalfJung
Copy link
Member Author

Rebased to resolve conflict (but it was a clean rebase); @matthewjasper this is ready for another round of review.

@matthewjasper
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 4, 2020

📌 Commit 66b340f has been approved by matthewjasper

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 4, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 4, 2020
…asper

do not apply DerefMut on union field

This implements the part of [RFC 2514](https://github.com/rust-lang/rfcs/blob/master/text/2514-union-initialization-and-drop.md) about `DerefMut`. Unlike described in the RFC, we only apply this warning specifically when doing `DerefMut` of a `ManuallyDrop` field; that is really the case we are worried about here.

@matthewjasper suggested I patch `convert_place_derefs_to_mutable` and `convert_place_op_to_mutable` for this, but I could not find anything to do in `convert_place_op_to_mutable` and this is sufficient to make the test pass. However, maybe there are some other cases this misses? I have no familiarity with this code.

This is a breaking change *in theory*, if someone used `ManuallyDrop<T>` in a union field and relied on automatic `DerefMut`. But on stable this means `T: Copy`, so the `ManuallyDrop` is rather pointless.

Cc rust-lang#55149
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 4, 2020
…asper

do not apply DerefMut on union field

This implements the part of [RFC 2514](https://github.com/rust-lang/rfcs/blob/master/text/2514-union-initialization-and-drop.md) about `DerefMut`. Unlike described in the RFC, we only apply this warning specifically when doing `DerefMut` of a `ManuallyDrop` field; that is really the case we are worried about here.

@matthewjasper suggested I patch `convert_place_derefs_to_mutable` and `convert_place_op_to_mutable` for this, but I could not find anything to do in `convert_place_op_to_mutable` and this is sufficient to make the test pass. However, maybe there are some other cases this misses? I have no familiarity with this code.

This is a breaking change *in theory*, if someone used `ManuallyDrop<T>` in a union field and relied on automatic `DerefMut`. But on stable this means `T: Copy`, so the `ManuallyDrop` is rather pointless.

Cc rust-lang#55149
@bors
Copy link
Contributor

bors commented Sep 5, 2020

⌛ Testing commit 66b340f with merge ea590e7b64fbc953a5d33618e5af7c32915f465e...

@bors
Copy link
Contributor

bors commented Sep 5, 2020

💔 Test failed - checks-actions

@bors bors removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Sep 5, 2020
@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 5, 2020
@rust-log-analyzer
Copy link
Collaborator

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

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 @rust-lang/infra. (Feature Requests)

@RalfJung
Copy link
Member Author

RalfJung commented Sep 5, 2020

Clang installation failure.
@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 5, 2020
@bors
Copy link
Contributor

bors commented Sep 5, 2020

⌛ Testing commit 66b340f with merge 81a769f...

@bors
Copy link
Contributor

bors commented Sep 5, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: matthewjasper
Pushing 81a769f to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 5, 2020
@bors bors merged commit 81a769f into rust-lang:master Sep 5, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 5, 2020
@RalfJung RalfJung deleted the union-no-deref branch September 8, 2020 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants