You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As noted in a comment by arielb1, the fn access_lvalue needs to check somewhere that the accessor actually has sufficient permissions for the operation being requested, aka no mutable borrows of immutable references or moves through a non-Box reference.
To elaborate, here are some examples of the kinds of scenarios we are worried about:
&mut of imm ref
For mutable borrows of immutable references, here is a case that mir-borrowck today does not properly catch (and, I think, none of the PR's in flight will fix):
Compiling this with -Z borrowck-mir on today's master yields this single error from the AST-borrowck alone:
error[E0596]: cannot borrow immutable borrowed content `*x` as mutable
--> check-access-lvalue.rs:3:19
|
3 | let rw = &mut *x;
| ^^ cannot borrow as mutable
error: aborting due to previous error
Move through non-Box ref
... hmm... I am having trouble constructing an example of this where AST-borrowck and MIR-borrowck differ in behavior. (Which is strange because I thought there was significant portions of box-support that remained to be implemented. I'll have to look more deeply into this.)
@zilbuz also notes this example (though I think it might a bit different thing to check, since this AFAICT is about checking that the local _a has a let mut declaration...)
In each case, there is a function that, given an lvalue, tells you whether it can be mutated or whether it can be moved from. The function returns Err(lv) if the action is illegal, in which case lv is the lvalue we can "blame" for that.
Activity
pnkfelix commentedon Oct 9, 2017
To elaborate, here are some examples of the kinds of scenarios we are worried about:
&mut
of imm refFor mutable borrows of immutable references, here is a case that
mir-borrowck
today does not properly catch (and, I think, none of the PR's in flight will fix):Compiling this with
-Z borrowck-mir
on today's master yields this single error from the AST-borrowck alone:Move through non-
Box
ref... hmm... I am having trouble constructing an example of this where AST-borrowck and MIR-borrowck differ in behavior. (Which is strange because I thought there was significant portions of box-support that remained to be implemented. I'll have to look more deeply into this.)
pnkfelix commentedon Oct 9, 2017
@zilbuz also notes this example (though I think it might a bit different thing to check, since this AFAICT is about checking that the local
_a
has alet mut
declaration...)fn access_lvalue
#45436nikomatsakis commentedon Nov 9, 2017
Here is some pseudocode for the various permissions I think we might want to check:
https://gist.github.com/nikomatsakis/90102114e8ba5792d4e28a6960942ae6
In each case, there is a function that, given an lvalue, tells you whether it can be mutated or whether it can be moved from. The function returns
Err(lv)
if the action is illegal, in which caselv
is the lvalue we can "blame" for that.Auto merge of #45436 - zilbuz:issue-44837, r=nikomatsakis
arielb1 commentedon Nov 15, 2017
The permission checks still let you assign/mutate through an immutable reference:
e.g. the test compile-fail/borrowck/borrowck-borrow-mut-base-ptr-in-aliasable-loc.rs
check_access_permissions()
#460412 remaining items