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

Use type based qualification for unions #90373

Merged
merged 1 commit into from
Oct 29, 2021

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Oct 28, 2021

Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.

For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain UnsafeCell constructor.

#![feature(untagged_unions)]

union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };

To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.

Fixes #90268.

@rust-lang/wg-const-eval

Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.

For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.

```rust
#![feature(untagged_unions)]

union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```

To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
@rust-highfive
Copy link
Collaborator

r? @wesleywiser

(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 Oct 28, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 28, 2021
@@ -258,6 +258,9 @@ where
if Q::in_adt_inherently(cx, def, substs) {
return true;
}
if def.is_union() && Q::in_any_value_of_ty(cx, rvalue.ty(cx.body, cx.tcx)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is correct, but conservative for things like drop, which unions must directly implement, it's never invoked on their fields. Will this get us in trouble wit ManuallyDrop in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is the concern here that we will look inside ManuallyDrop and qualify value as needing drop based on the inner content? That seems like a possible issue, but more for already existing implementation, not for the new one?

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm good point. Ok. I'm convinced about this PR XD

src/test/ui/consts/qualif-union.rs Show resolved Hide resolved
@oli-obk
Copy link
Contributor

oli-obk commented Oct 28, 2021

r? @oli-obk

@oli-obk
Copy link
Contributor

oli-obk commented Oct 28, 2021

@bors r+

@bors
Copy link
Contributor

bors commented Oct 28, 2021

📌 Commit 3f778f3 has been approved by oli-obk

@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 Oct 28, 2021
@bors
Copy link
Contributor

bors commented Oct 29, 2021

⌛ Testing commit 3f778f3 with merge 9ed5b94...

@bors
Copy link
Contributor

bors commented Oct 29, 2021

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 9ed5b94 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 29, 2021
@bors bors merged commit 9ed5b94 into rust-lang:master Oct 29, 2021
@rustbot rustbot added this to the 1.58.0 milestone Oct 29, 2021
@tmiasko tmiasko deleted the union-qualification branch October 29, 2021 17:02
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (9ed5b94): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

tmiasko added a commit to tmiasko/rust that referenced this pull request Dec 31, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 31, 2021
Extend check for UnsafeCell in consts to cover unions

A validity companion to changes from rust-lang#90373.

`@rust-lang/wg-const-eval`
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should unions use type based const qualification?
8 participants