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

Mark places as initialized when mutably borrowed #90788

Merged
merged 4 commits into from
Nov 23, 2021

Conversation

ecstatic-morse
Copy link
Contributor

@ecstatic-morse ecstatic-morse commented Nov 11, 2021

Fixes the example in #90752, but does not handle some corner cases involving raw pointers and unsafe. See this comment for more information, or the second test.

Although I talked about both MaybeUninitializedPlaces and MaybeInitializedPlaces in #90752, this PR only changes the latter. That's because "maybe uninitialized" is the conservative choice, and marking them as definitely initialized (!maybe_uninitialized) when a mutable borrow is created could lead to problems if addr_of_mut to an uninitialized local is allowed. Additionally, places cannot become uninitialized via a mutable reference, so if a place is definitely initialized, taking a mutable reference to it should not change that.

I think it's correct to ignore interior mutability as nbdd0121 suggests below. Their analysis doesn't work inside of core::cell, which does have access to UnsafeCell's field, but that won't be an issue unless we explicitly instantiate one with an enum within that module.

r? @wesleywiser

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 11, 2021
@ecstatic-morse ecstatic-morse marked this pull request as draft November 11, 2021 00:38
@rust-log-analyzer

This comment has been minimized.

@ecstatic-morse ecstatic-morse changed the title Mark places as maybe {un,}initialized when mutably borrowed Mark places as initialized when mutably borrowed Nov 11, 2021
@nbdd0121
Copy link
Contributor

nbdd0121 commented Nov 12, 2021

I don't think we need to worry about interior mutability, since it is always behind UnsafeCell. As there is no way to access the value field directly, move paths into the value wouldn't be used.

@rust-log-analyzer

This comment has been minimized.

@ecstatic-morse ecstatic-morse force-pushed the issue-90752 branch 2 times, most recently from bd9d8b7 to b8f6ab5 Compare November 13, 2021 19:12
@rust-log-analyzer

This comment has been minimized.

@ecstatic-morse ecstatic-morse marked this pull request as ready for review November 13, 2021 19:31
@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@nbdd0121 nbdd0121 left a comment

Choose a reason for hiding this comment

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

LGTM overall

@@ -0,0 +1,41 @@
// run-pass
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe instead of checking that we are getting the wrong result we should just have ignore-test FIXME(#90788)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If someone (including me) were to change the behavior of this test, they should be made aware.

// Ideally, we want this...
//assert_eq!(*drops.borrow(), &[0, 1]);

// But the delayed access through the raw pointer confuses drop elaboration,
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 unfortunate. Do you have an idea about how this could be fixed in the future?

Copy link
Contributor Author

@ecstatic-morse ecstatic-morse Nov 13, 2021

Choose a reason for hiding this comment

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

We typically handle this is by assuming that any variable which has been mutably borrowed at some point in the CFG could change at any subsequent point. The correctness of that approach doesn't depend on stacked borrows.

We can't implement it directly on top of MaybeInitializedPlaces, however, since it would break code that moves out of a variable after taking a mutable reference to it. We would need two state vectors like #90214 has, preferably only in drop elaboration where the increased precision from tracking variants is worthwhile. I think tracking variants does nothing for the borrow checker since it still has FalseEdges.

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 18, 2021
@ecstatic-morse
Copy link
Contributor Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 18, 2021
@bors
Copy link
Contributor

bors commented Nov 18, 2021

⌛ Trying commit 22d937d with merge 4853c802647b3e589b9ce14db5494a242b6f44e4...

@bors
Copy link
Contributor

bors commented Nov 18, 2021

☀️ Try build successful - checks-actions
Build commit: 4853c802647b3e589b9ce14db5494a242b6f44e4 (4853c802647b3e589b9ce14db5494a242b6f44e4)

@rust-timer
Copy link
Collaborator

Queued 4853c802647b3e589b9ce14db5494a242b6f44e4 with parent 6414e0b, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (4853c802647b3e589b9ce14db5494a242b6f44e4): comparison url.

Summary: This change led to very large relevant regressions 😿 in compiler performance.

  • Very large regression in instruction counts (up to 5.4% on incr-unchanged builds of inflate)

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

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Nov 18, 2021
Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

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

I'm inclined to merge but I would really appreciate a review from someone more familiar with the drop elaboration code. @ecstatic-morse do you know anyone else who we should ask to review?

return;
}

for_each_mut_borrow(terminator, location, |place| {
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Can you go ahead and copy the comment from line 322 here as well? Seems like we should try to keep these as similar as possible.

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented Nov 18, 2021

do you know anyone else who we should ask to review?

The original author (arielb1) is no longer active. You could "ask one of the elders", especially eddyb, who came up with the original idea for #68528 where I introduced the bug. I don't know how much free time they have for Rust reviews, though, and I try to avoid filling up their GitHub notifications.

@wesleywiser
Copy link
Member

@ecstatic-morse Thanks for resolving this issue so quickly! I think we should probably open a new issue to track the raw pointer bug, but for now let me

@bors r+

Sorry for the delay!

@bors
Copy link
Contributor

bors commented Nov 23, 2021

📌 Commit 22d937d has been approved by wesleywiser

@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 Nov 23, 2021
@jyn514
Copy link
Member

jyn514 commented Nov 23, 2021

@bors p=1 - this fixes unsoundness and should land before the beta branch on Friday

@bors
Copy link
Contributor

bors commented Nov 23, 2021

⌛ Testing commit 22d937d with merge 7b3cd07...

@bors
Copy link
Contributor

bors commented Nov 23, 2021

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 7b3cd07 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 23, 2021
@bors bors merged commit 7b3cd07 into rust-lang:master Nov 23, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 23, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7b3cd07): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

  • Moderate regression in instruction counts (up to 0.6% on full builds of match-stress-enum)

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

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

@nbdd0121
Copy link
Contributor

Needs backport

@Mark-Simulacrum Mark-Simulacrum added beta-nominated Nominated for backporting to the compiler in the beta channel. and removed beta-nominated Nominated for backporting to the compiler in the beta channel. labels Nov 30, 2021
@Mark-Simulacrum
Copy link
Member

Discussed in T-compiler meeting last week - https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202021-11-24.20.2354818/near/262604287 and decided to forgo a backport to 1.57 (shipping this week). This will be in 1.58, though.

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. perf-regression Performance regression. 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.