-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Conversation
This comment has been minimized.
This comment has been minimized.
07ebe18
to
ce67b89
Compare
I don't think we need to worry about interior mutability, since it is always behind |
ce67b89
to
be7944f
Compare
This comment has been minimized.
This comment has been minimized.
bd9d8b7
to
b8f6ab5
Compare
This comment has been minimized.
This comment has been minimized.
b8f6ab5
to
aedb844
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
.
aedb844
to
22d937d
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 22d937d with merge 4853c802647b3e589b9ce14db5494a242b6f44e4... |
☀️ Try build successful - checks-actions |
Queued 4853c802647b3e589b9ce14db5494a242b6f44e4 with parent 6414e0b, future comparison URL. |
Finished benchmarking commit (4853c802647b3e589b9ce14db5494a242b6f44e4): comparison url. Summary: This change led to very large relevant regressions 😿 in compiler performance.
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 @bors rollup=never |
There was a problem hiding this 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| { |
There was a problem hiding this comment.
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.
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. |
@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! |
📌 Commit 22d937d has been approved by |
@bors p=1 - this fixes unsoundness and should land before the beta branch on Friday |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7b3cd07): comparison url. Summary: This change led to moderate relevant regressions 😿 in compiler performance.
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 |
Needs backport |
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. |
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
andMaybeInitializedPlaces
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 ifaddr_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 toUnsafeCell
's field, but that won't be an issue unless we explicitly instantiate one with anenum
within that module.r? @wesleywiser