-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Fix borrow checker unsoundness with unions #47689
Conversation
|
src/test/ui/issue-45157.rs
Outdated
let mut u = U { s: Default::default() }; | ||
|
||
let mref = &mut u.s.a; //~ ERROR cannot assign twice to immutable variable `mref` [E0384] | ||
let err = &u.z.c; //~ ERROR cannot assign twice to immutable variable `err` [E0384] |
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.
The code as is should compile with nll. There needs to be a second use of mref to keep the borrow active for the second assignment.
src/librustc_mir/borrow_check/mod.rs
Outdated
debug!("place_element_conflict: DISJOINT-LOCAL"); | ||
Overlap::Disjoint | ||
}, | ||
} |
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 think this is not quite right. Local variables should always be disjoint from one another. For example, borrowing x
while y
is borrowed should never be an error, no matter the type of x
.
Going to modify this PR to add a test to handle the case @nikomatsakis mentioned in the issue since whichever problem this issue originally referred to is now being handled. |
3ff0190
to
18fd3f6
Compare
18fd3f6
to
e6376a1
Compare
| ^^^^^^ immutable borrow occurs here | ||
|
||
error[E0502]: cannot borrow `u.s.a` as mutable because it is also borrowed as immutable | ||
--> $DIR/issue-45157.rs:39:27 |
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 second error is a bit surprising. I don't quite understand what it is saying, it looks a bit fishy.
cc @pnkfelix -- agreed?
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.
Are you saying that there should be no error here at all? Or just that the error should be focused on prefixes of the field projections it is currently highlighting?
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 do not think there should be an error at all, and certainly not with these spans. Usually something like this:
let mut a = 2;
let mref = &mut a;
let nref = &a;
println("{}{}", mref, nref);
gives only one error, right?
i.e., one borrow comes first, and it "wins"
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.
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.
So, looking into this a little bit, here is what I've figured out:
rust/src/librustc_mir/util/borrowck_errors.rs
Lines 225 to 247 in fd0f292
fn cannot_reborrow_already_borrowed(&self, | |
span: Span, | |
desc_new: &str, | |
msg_new: &str, | |
kind_new: &str, | |
old_span: Span, | |
noun_old: &str, | |
kind_old: &str, | |
msg_old: &str, | |
old_load_end_span: Option<Span>, | |
o: Origin) | |
-> DiagnosticBuilder | |
{ | |
let mut err = struct_span_err!(self, span, E0502, | |
"cannot borrow `{}`{} as {} because {} is also borrowed as {}{}{OGN}", | |
desc_new, msg_new, kind_new, noun_old, kind_old, msg_old, OGN=o); | |
err.span_label(span, format!("{} borrow occurs here{}", kind_new, msg_new)); | |
err.span_label(old_span, format!("{} borrow occurs here{}", kind_old, msg_old)); | |
if let Some(old_load_end_span) = old_load_end_span { | |
err.span_label(old_load_end_span, format!("{} borrow ends here", kind_old)); | |
} | |
self.cancel_if_wrong_origin(err, o) | |
} |
The error is reported in the above function. That is called by the following function:
rust/src/librustc_mir/borrow_check/error_reporting.rs
Lines 259 to 272 in fdecb05
(BorrowKind::Shared, lft, _, BorrowKind::Mut, _, rgt) | | |
(BorrowKind::Mut, _, lft, BorrowKind::Shared, rgt, _) => self.tcx | |
.cannot_reborrow_already_borrowed( | |
span, | |
&desc_place, | |
"", | |
lft, | |
issued_span, | |
"it", | |
rgt, | |
"", | |
end_issued_loan_span, | |
Origin::Mir, | |
), |
This is quite similar to the work done for #47607, in that PR, I added a set that contains the place/span of any errors reported so that they aren't reported again. In this case, the span on line 37 on the below error (that we want) would be in this set:
error[E0502]: cannot borrow `u.z.c` as immutable because it is also borrowed as mutable
--> src/main.rs:37:20
|
34 | let mref = &mut u.s.a; //~ ERROR cannot assign twice to immutable variable `mref` [E0384]
| ---------- mutable borrow occurs here
...
37 | let nref = &u.z.c; //~ ERROR cannot assign twice to immutable variable `err` [E0384]
| ^^^^^^ immutable borrow occurs here
I'm not entirely sure what the unintended side effects of the following might be, but we could check if the issued_span
is in the set (in the above example, that is the error on line 34, but in the second unintended error, that would refer to the same location as above on line 37) and if it is, skip this error. It would essentially silence errors that overlap where the second borrow location of the first error is the first borrow location in subsequent errors. Thoughts?
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.
@davidtwco do you think you could gist the output from -Zdump-mir=nll
for this function?
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.
@nikomatsakis is this what you're looking for?
https://gist.github.com/nikomatsakis/b0ac3440933b3ae1d4dc3db02d738111
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.
yep but I was hoping for a gist :) kind of hard to digest inline...
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.
updated your comment =)
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.
Here is a gist with some logging added in access_place
and check_access_for_conflict
that should show the variable values. Lines 13730 to 13759 for the first error and lines 13912 to 13959 for the second error.
Ping from triage @nikomatsakis! |
@nikomatsakis ping from triage! |
So I did a bit of digging here, IIRC, and found that the strange errors arose from two-phase borrows. I did not however get far enough to decide if this was a distinct bug or what. |
@nikomatsakis and @rust-lang/compiler, can we get a review on this? |
I was still hoping that @pnkfelix would weigh in. But I still hope to carve out some time to dig in to the two-phase borrow logic and try to understand just why it's triggering in the way that it is and how we can improve it. |
@nikomatsakis oh, sorry, I didn't know you were still waiting on further input from me |
@pnkfelix so I think the problem was that whenever we saw a Gen bit for an activation, we treated that as an activation that needs checking. I think that should only be required for loans that are not already activated. I made that change in the most recent commit. Can you review it? |
hmm, in gitter just now, @pnkfelix and I were saying we had some concern about the possibility of an activation being overlooked due to an activation from a previous loop |
So it seems like what we need is some way to know when one activation is dominated by another (in which case it can be ignored). Because activations are "unioned" on control-flow join, we don't get that for free. Annoying. We could make a "must be activated" dataflow, but it feels like overkill to me. |
That said, this seems orthogonal from the original PR. Why don't we do this -- I'll peel off my last two commits and we'll open up a separate issue to discuss the extra errors resulting from two-phase borrows. Then we can land this PR, which fixes a legit problem. |
c27e29e
to
e6376a1
Compare
@bors r+ rollup |
📌 Commit e6376a1 has been approved by |
I opened #48418 |
Fix borrow checker unsoundness with unions Fixes rust-lang#45157. After discussion with @nikomatsakis on Gitter, this PR only adds a test since the original issue was resolved elsewhere. r? @nikomatsakis
Fixes #45157. After discussion with @nikomatsakis on Gitter, this PR only adds a test since the original issue was resolved elsewhere.
r? @nikomatsakis