Unclear error E0594

[StyMaar]

When attempting to mutate a field of a borrowed struct (with a shared reference &) we get the unhelpful E5094 error :

error[E0594]: cannot assign to field reagent.unreserved_volume of immutable binding [emphasis mine]

Sample code :

fn main() {
    let foo = &Bar{x: 5}; // or any function that returns a shared reference
    foo.x -= 12;
}

struct Bar {
    x: i32
}

Error :

| foo.x -= 12;
| ^^^^^^^^^^^ cannot mutably borrow field of immutable binding

Since the compiler complains about a “binding” being immutable, my reflex was to add a mut at foo's declaration site :

fn main() {
    let mut foo = &Bar{x: 5}; // or any function that returns a shared reference
    foo.x -= 12;
}

struct Bar {
    x: i32
}

Which didn't change anything. (except adding a warning that I didn't notice)

The problem here, is that the error message is complaining about an immutable binding whereas it should complain about an immutable (or shared) reference.

To add insult to injury, the error E0594 doesn't exist in the error index and rustc --explain E0594 returns the laconic

error: no extended information for E0594

Meta

rustc --version --verbose:

rustc 1.29.0-nightly (e94df4a 2018-07-31)
binary: rustc
commit-hash: e94df4a
commit-date: 2018-07-31
host: x86_64-unknown-linux-gnu
release: 1.29.0-nightly
LLVM version: 7.0

The behavior is the same on Stable 1.27.2 though.

[StyMaar]

Additional note : it's not just a problem with the error message of E0594, since the same error is also raised when it's actually a immutable binding problem :

fn main() {
 let y = 0f32;
 let foo = Bar{x: 0f32};
 foo.x= y;
}

struct Bar {
    x: f32
}

It should just be another error kind raised in the situation described by this issue. (And also E0594 should probably appear in the error index and as a result of rustc --explain E0594)

[pnkfelix]

I think NLL does a better job with error message here.

Look at the output when you run with 2018 edition enabled (playground):

error[E0594]: cannot assign to `foo.x` which is behind a `&` reference
 --> src/main.rs:3:5
  |
2 |     let foo = &Bar{x: 5}; // or any function that returns a shared reference
  |               ---------- help: consider changing this to be a mutable reference: `&mut Bar{x: 5}`
3 |     foo.x -= 12;
  |     ^^^^^^^^^^^ `foo` is a `&` reference, so the data it refers to cannot be written

[pnkfelix]

(as in, it may be reasonable to tag this as NLL-fixed-by-NLL...)

[pnkfelix]

Likewise, here's what NLL does for the second provided example (playground):

error[E0384]: cannot assign twice to immutable variable `foo`
 --> src/main.rs:4:2
  |
3 |  let foo = Bar{x: 0f32};
  |      ---
  |      |
  |      first assignment to `foo`
  |      consider changing this to `mut foo`
4 |  foo.x = y;
  |  ^^^^^^^^^ cannot assign twice to immutable variable

which I think also satisfies the request written in the comment above?

[StyMaar]

You're right, that's way better with NLL !

I'm a bit surprised that enabling 2018 edition activates NLL: does that mean that NLL will be limited to the 2018 edition ?

[StyMaar]

That also means that with NLL, the meaning a E0594 is changing (from «immutable binding error» also triggered in case of «immutable reference error» to «immutable reference error» only).

[pnkfelix]

I'm a bit surprised that enabling 2018 edition activates NLL: does that mean that NLL will be limited to the 2018 edition ?

No, not in the long term.

For the short term, we are connecting the enabling of NLL to the 2018 edition as a way to try to get it tested by people who are willing to deal with the headaches NLL might imply in its current state.

• These headaches include various diagnostic regressions and compiler performance regressions, all of which we hope to resolve.
• And to be honest, I also am happy to attach NLL to the 2018 edition for the short term, so that we can add it to the list of cool stuff that will encourage people to try out the 2018 edition ASAP.

In the long term, we are planning to move everybody to NLL, regardless of edition. The schedule for when that will happen hasn't been established yet; I suspect it will depend on the feedback we get from 2018 edition preview 2.

• But I wouldn't be surprised if we turn NLL (at least in its current migration mode) on across the board at the same time that we release the final version of the 2018 edition.

[StyMaar]

Thanks for your answers. I think I can close the issue.

[dustinfreeman]

I just want to chime in – I found E0594's message to still be confusing even when using Rust 2018 Edition, version 1.31. I'm only 1 month into using Rust, and in the code below I was mis-using Rc:

use std::rc::Rc;
use std::cell::RefCell;

#[derive(Debug)]
struct TestStruct {
    u: u32,
}

fn main() {
    let mut val = TestStruct{ u: 1 };
    val.u += 2;
    println!("val {:?} ", val);
    //prints: val TestStruct { u: 3 }
    
    let mut val_rc = Rc::new(TestStruct{ u: 10 });    
    //above I mistakenly assumed "mut" would let me mutate the subcontents of the Rc.
    val_rc.u += 2;
    //above creates compile error: error[E0594]: cannot assign to data in a `&` reference
    println!("val_rc {:?} ", val_rc);    

    //The solution I used
    let val_rc_refcell = Rc::new(RefCell::new(TestStruct{ u: 20 }));
    (*val_rc_refcell).borrow_mut().u += 2;
    println!("val_rc_refcell {:?} ", val_rc_refcell);        
}

Can we hope for a clearer error message than error[E0594]: cannot assign to data in a & reference ?

[StyMaar]

I'm re-opening this issue because of what @dustinfreeman said, and because E0594 is still not part of the error index.

[cumbreras]

agreed, this would be helpful, as I've found myself last couple of days falling to find it.

[estebank]

The error index work is tracked in #61137. Extending E0594 to be more useful is tracked in #18150.

[pnkfelix]

reopening as the modern, more narrowly focused version of #18150

(though really, an entirely new issue might be warranted at this point, to avoid the discussion of NLL and what not...)

[pnkfelix]

marking P-high to reflect desired prioritization of @estebank , and assigning to self.

[Qqwy]

Note that as of January 2020, this E0594 still is not part of the error index.

[estebank]

@Qqwy that work is tracked in #61137.

[estebank]

@Qqwy that work is tracked in #61137. This error code has been added to the index.