regression: cannot borrow ... as immutable because it is also borrowed as mutable

[INFO] [stdout] error[E0502]: cannot borrow `*inputs` as immutable because it is also borrowed as mutable
[INFO] [stdout]    --> examples/basic.rs:267:27
[INFO] [stdout]     |
[INFO] [stdout] 263 |           if let Some(grd) = inputs[0].grad.as_mut() {
[INFO] [stdout]     |                              -------------- mutable borrow occurs here
[INFO] [stdout] 264 | /             *grd += output_grad
[INFO] [stdout] 265 | |                 * if inputs[0].val > 0.0 {
[INFO] [stdout] 266 | |                     1.0
[INFO] [stdout] 267 | |                 } else if inputs[0].val == 0.0 {
[INFO] [stdout]     | |                           ^^^^^^^^^ immutable borrow occurs here
[INFO] [stdout] ...   |
[INFO] [stdout] 270 | |                     -1.0
[INFO] [stdout] 271 | |                 };
[INFO] [stdout]     | |_________________- mutable borrow later used here

@scottmcm

This regressed in #133734 cc @scottmcm

instead -- with some asterisks for arrays and &mut that need it to be done slightly differently.

I assume that maybe there was something missing here 🤔

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 Len operand), 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 Len operand 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 the RawPtr operand (&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 treat RawPtr operands like borrows, so the metadata access for let b = ... is treated like an access conflict with the mutable reference of let 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 🤔

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 bar2 in 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)
}

@steffahn

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.

Auto merge of rust-lang#135709 - lqd:bring-back-len, r=compiler-errors

Fixed on nightly. Reopening to track beta backport.

Reopening as #135709 wasn't merged.

This was already fixed on nightly. #136352 unblocked fixing it on beta. Reopening to track beta backport of #135709.

#136650 backported the fix to beta.

Auto merge of rust-lang#135709 - lqd:bring-back-len, r=compiler-errors

Auto merge of #135709 - lqd:bring-back-len, r=compiler-errors

Navigation Menu

Repository navigation

regression: cannot borrow ... as immutable because it is also borrowed as mutable #135671

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

regression: cannot borrow ... as immutable because it is also borrowed as mutable #135671

Description

Activity

compiler-errors commented on Jan 18, 2025

compiler-errors commented on Jan 18, 2025

compiler-errors commented on Jan 18, 2025

steffahn commented on Jan 18, 2025

compiler-errors commented on Jan 18, 2025

lqd commented on Jan 19, 2025

6 remaining items

lqd commented on Jan 29, 2025

lqd commented on Feb 3, 2025

cuviper commented on Feb 7, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions