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

Extend check for UnsafeCell in consts to cover unions #90383

Merged
merged 1 commit into from
Jan 1, 2022

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Oct 28, 2021

A validity companion to changes from #90373.

@rust-lang/wg-const-eval

@rust-highfive
Copy link
Collaborator

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive
Copy link
Collaborator

r? @michaelwoerister

(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
@rust-log-analyzer

This comment has been minimized.

// Note that this test case relies on undefined behaviour to construct a
// constant with interior mutability that is "invisible" to the static checks.
// If for some reason this approach no longer works, it is should be fine to
// remove the test case.
Copy link
Member

Choose a reason for hiding this comment

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

Wow, what a test. :D

That said, which part of this test causes UB? With a repr, I think changing the tag of an enum via raw ptr manipulation is totally fine. It seems promotion analysis is making some IMO unfounded assumptions if it thinks the tag cannot change here.

Copy link
Member

Choose a reason for hiding this comment

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

Oh wait, you are writing through a shared ref. That is more tricky... though the exact scope of UnsafeCell inside enums is not decided yet, so this is not as clear-cut as one might think at first sight. For example, for an Option<Cell<NonZeroI32>>, mutating the discriminant through a shared ref is almost certainly going to be allowed.
Cc rust-lang/unsafe-code-guidelines#204 rust-lang/unsafe-code-guidelines#236

Copy link
Member

@BoxyUwU BoxyUwU Oct 29, 2021

Choose a reason for hiding this comment

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

For example, for an Option<Cell<NonZeroI32>>, mutating the discriminant through a shared ref is almost certainly going to be allowed.

was this a typo? I thought this specifically wasnt allowed, we made UnsafeCell inhibit niches, i.e. size_of::<Option<UnsafeCell<NonZeroU32>>>() == 8

edit: oh no I just checked and it doesnt apply when the unsafecell is newtyped..? That seems bad

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Test case creates a reference to S::x field which has a u32 type, so no interior mutability here. The const qualification assumes that resulting pointer cannot be used to access the other parts of a local. The assumption is violated here by offsetting the pointer and overwriting an adjacent tag.

edit: oh no I just checked and it doesnt apply when the unsafecell is newtyped..? That seems bad

Good catch. I think we already have an open issue for niche hiding not working exactly as intended.

Copy link
Member

Choose a reason for hiding this comment

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

Ah right UnsafeCell masks niches these days (except when newtpyed but that is a bug: #87341).

Test case creates a reference to S::x field which has a u32 type, so no interior mutability here. The const qualification assumes that resulting pointer cannot be used to access the other parts of a local. The assumption is violated here by offsetting the pointer and overwriting an adjacent tag.

Ah I see. So this makes certain assumptions about the aliasing model, but this particular case is probably fine -- however, I am still a bit worried that promotion analysis might make more assumptions than we can actually uphold. In this case we are creating an &T where T: Freeze. But if we ever do anything value-based here (e.g., &None::<T> where T might be !Freeze), that would be sketchy.

@RalfJung
Copy link
Member

r? @RalfJung

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 11, 2021
@JohnCSimon JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 5, 2021
@RalfJung
Copy link
Member

Sorry, this fell through the cracks because GH does not always send email notifications for force-pushes. This change makes sense to me.

@bors r+

@bors
Copy link
Contributor

bors commented Dec 30, 2021

📌 Commit c750d7e8620ba05a3c07583c1630523e50bfa8b7 has been approved by RalfJung

@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 Dec 30, 2021
@bors
Copy link
Contributor

bors commented Dec 31, 2021

⌛ Testing commit c750d7e8620ba05a3c07583c1630523e50bfa8b7 with merge eb69c9f6df723a8cceb0aeefcf93a9ffbabe38a4...

@bors
Copy link
Contributor

bors commented Dec 31, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 31, 2021
@rust-log-analyzer

This comment has been minimized.

@tmiasko
Copy link
Contributor Author

tmiasko commented Dec 31, 2021

Rebased and updated the test output.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Dec 31, 2021

📌 Commit 2eb637a has been approved by RalfJung

@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 Dec 31, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 31, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#90383 (Extend check for UnsafeCell in consts to cover unions)
 - rust-lang#91375 (config.rs: Add support for a per-target default_linker option.)
 - rust-lang#91480 (rustdoc: use smaller number of colors to distinguish items)
 - rust-lang#92338 (Add try_reserve and  try_reserve_exact for OsString)
 - rust-lang#92405 (Add a couple needs-asm-support headers to tests)
 - rust-lang#92435 (Sync rustc_codegen_cranelift)
 - rust-lang#92440 (Fix mobile toggles position)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ac1060e into rust-lang:master Jan 1, 2022
@rustbot rustbot added this to the 1.59.0 milestone Jan 1, 2022
@tmiasko tmiasko deleted the union-validity branch January 1, 2022 06:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

10 participants