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
{{ message }}
Repository navigation
NLL diagnostics for ref mut z @ &mut Some(ref a) uses _ as binding name #67565
error[E0502]: cannot borrow `_` asimmutable because it is also borrowed asmutable
--> $DIR/borrowck-pat-ref-mut-and-ref.rs:11:31
|
LL | ref mut z @ &mut Some(ref a) => {
| ----------------------^^^^^-
| | |
| | immutable borrow occurs here
| mutable borrow occurs here
...
LL | **z = None;
| ---------- mutable borrow later used here
I feel like the internal use of _ as a default name for things is a bit undisciplined, and it's leaking into diagnostics in annoying ways. There is also this: #66679
I feel like internally, we should keep a strong separation between names that we get from the source code being compiled and names being generated by the compiler...
I think this issue is about the narrow issue of why this happens in the case of ref mut x @ Some(ref y) though whereas it doesn't happen in other cases.
@Centril Sure, but I think it stems from a larger problem of undisciplined use of _ in various places... If we don't fix that, then we will get weird bugs like this showing up again later even if we fix this particular example....
Activity
mark-i-m commentedon Dec 28, 2019
I feel like the internal use of
_as a default name for things is a bit undisciplined, and it's leaking into diagnostics in annoying ways. There is also this: #66679I feel like internally, we should keep a strong separation between names that we get from the source code being compiled and names being generated by the compiler...
Centril commentedon Dec 28, 2019
I think this issue is about the narrow issue of why this happens in the case of
ref mut x @ Some(ref y)though whereas it doesn't happen in other cases.mark-i-m commentedon Dec 29, 2019
@Centril Sure, but I think it stems from a larger problem of undisciplined use of
_in various places... If we don't fix that, then we will get weird bugs like this showing up again later even if we fix this particular example....Centril commentedon Dec 29, 2019
@mark-i-m I don't mind fixing this by fixing the root cause, but can we discuss the bigger issue in a issue made for that and cc this one?
Centril commentedon Feb 17, 2020
Investigation
Source input:
Results in the following MIR:
And we double check with some
debug!s inast_block_stmts(in theif let Some(init) = initializer {branch):using
RUSTC_LOG=rustc_mir_build::build::block=debug rustc +gamma-stage1 -Z dump-mir=nll foo.rswe get:Borrow checking trace:
The error comes from
describe_place_for_conflicting_borrow, which is fed:We eventually end up in
append_local_to_string, where we have (with some changes to the code):and so it tries to compute
self.local_names[_3]which gives usNoneand hence there is no name.The unchanged log output on master is:
Rollup merge of rust-lang#70389 - Centril:borrowck-no-underscores, r=…