Repository navigation
regression: cannot borrow ... as immutable because it is also borrowed as mutable #135671
Description
- https://crater-reports.s3.amazonaws.com/beta-1.85-1/beta-2025-01-12/gh/LP-Finance-Inc.twamm/log.txt
- https://crater-reports.s3.amazonaws.com/beta-1.85-1/beta-2025-01-12/gh/Mokosha.pbrt_rust/log.txt
- https://crater-reports.s3.amazonaws.com/beta-1.85-1/beta-2025-01-12/gh/jw1912.diffable/log.txt
Activity
- added a parent issue
on Jan 18, 2025 Minimal:
struct Test { a: i32, b: i32, } fn main() { let inputs: &mut [_] = &mut [Test { a: 0, b: 0 }]; let a = &mut inputs[0].a; let b = &mut inputs[0].b; *a = 0; *b = 1; }
I think we should probably revert #133734 (and the follow-up PR that fully removed the
Lenoperand), and spend some more time on a solution that is both resilient to borrowck and also to miri.Specifically, the problem here is that the borrow-checker treated the
Lenoperand specially (as a kind of fake borrow) which allowed it to be interleaved with mutable live mutable references pointing into the slice. The same does not apply to theRawPtroperand (&raw const) that we emit as part of the new lowering (all of this happens because we must read the slice length to emit a bounds check before slice accesses). Instead, in MIR borrowck, we currently treatRawPtroperands like borrows, so the metadata access forlet b = ...is treated like an access conflict with the mutable reference oflet a = ....After this revert, we could either think about:
- Changing the semantics of
&raw (const|mut)operand in borrowck to not act like an access - Emitting a new kind of special copy operand (much like
CopyForDeref) that allows us to treat the access of an array for length access as disjoint. - Some other solution...
However, in the mean time, I'd rather we not crunch trying to find and more importantly validate the soundness of a solution 🤔
- Changing the semantics of
Oh wow, that minimal repro is … just normal code very deliberately supported by borrow checking for a long time!? There was no UI test for that? I’ve even shared code examples like this in the forums before … multiple times o.O
(One example is here, e.g. the very first code block is broken on beta. And here’s another one, the example
bar2in the playground behind the last paragraph’s link.)I suppose, this means I should write down some of this stuff as UI tests, right?
By the way, tuples could be used, too… e.g. for a minimal repro without defining a
struct:fn main() { let slice = &mut [(0, 0)][..]; std::mem::swap(&mut slice[0].0, &mut slice[0].1); }
And here’s an example similar to the latter one of my forum-examples linked above
fn foo(a: &mut [(i32, i32)], i: usize, j: usize) -> (&mut i32, &mut i32) { (&mut a[i].0, &mut a[j].1) }
I suppose, this means I should write down some of this stuff as UI tests, right?
@steffahn: If you want to contribute some tests that exercise disjoint borrows, feel free to. I'll review them.
Reacted by Frank SteffahnFixed on nightly. Reopening to track beta backport.
6 remaining items
- linked a pull request that will close this issueAdd a couple of missing `ensure_sufficient_stacks` #136352
on Jan 31, 2025
