Lesson 6. Reading a Borrow Error

Mission link: This closes the stage. Its success criterion is predicting a move or borrow error before the compiler reports it, and the way there is a small vocabulary of error codes plus the habit of asking what the compiler was actually asking.
Primary source: Rust Compiler Error Index
Prerequisites: Lesson 2, Lesson 3, Lesson 5

Warm-up

1. ▢ What is the difference between mut x and &mut x?

2. ▢ Which of these ends a shared borrow: the end of the enclosing scope, or its last use?

Know this

An error message from rustc has four parts, and people read one of them:

error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
 --> src/main.rs:4:5
  |
3 |     let first = &v[0];
  |                  - immutable borrow occurs here
4 |     v.push(4);
  |     ^^^^^^^^^ mutable borrow occurs later here
5 |     println!("{first}");
  |               ------- immutable borrow later used here

The headline names the conflict. The spans name three lines: where the first borrow began, where the conflicting one is, and where the first borrow is still used. That third span is the one that matters, because it tells you what is keeping the borrow alive, which is usually the line you can move.

rustc --explain E0502 prints the error code's page with a minimal reproduction, offline.

The five codes that cover stage 1

Two more arrive in stage 4, and they are the boundary of this stage rather than part of it: E0106, a missing lifetime specifier, and E0597, a value that does not live long enough. Both mean the compiler cannot work out how long a reference is meant to be valid, which is a question this stage never asks.

The four honest fixes

Given a borrow or move error, one of these is right:

1. End the borrow sooner. Move the last use above the conflicting line, or wrap it in a block. Costs nothing, and works surprisingly often because borrows end at their last use.
2. Copy the value out instead of borrowing. For a Copy type, let x = v[0]; retains no borrow at all.
3. Change the signature to borrow. fn f(s: &str) instead of fn f(s: String). This is the fix for most E0382.
4. Restructure so one owner is enough. Split a struct so the two fields being borrowed separately are separate, or compute one value before mutating rather than interleaving.

The four workarounds, and what each costs

These also compile. Each is correct in a narrow case and a mistake as a reflex:

The distinction is not moral, it is about information. The error was a question about who owns the value and for how long. Fixes 1 to 4 answer it; the workarounds change the subject.

A worked triage

struct Server { config: Config, cache: Cache }

impl Server {
    fn refresh(&mut self) {
        let name = &self.config.name;          // shared borrow of self.config
        self.cache.insert(name);               // needs &mut self.cache
    }
}

That compiles, and the reason is worth knowing: the compiler tracks borrows of disjoint fields separately, so borrowing self.config and mutating self.cache do not conflict.

Now make it fail:

    fn refresh(&mut self) {
        let name = self.name();                // &self: borrows ALL of self
        self.cache.insert(name);               // E0502
    }

Calling a method that takes &self borrows the whole struct, so the disjointness is lost. The honest fixes, in order: have name() return an owned String when it is cheap; or read the field directly rather than through a method; or split the struct so the two parts can be borrowed independently. Cloning self.config would also compile and answers a question nobody asked.

The habit

Before running the compiler on code you are unsure about, ask three questions in order:

1. Does anything take ownership here, and does it need to?
2. Which borrows are live at this line, and where is each one last used?
3. Are the two things being borrowed actually the same value, or two fields the compiler will treat separately?

Predicting the error is the skill. The compiler is a very fast way to check the prediction, and using it as the first step rather than the second is how people spend a year fighting it.

Practice

1. ▢ Name the error code and the honest fix.

   let s = String::from("hi");
   let t = s;
   println!("{s}");
   

2. ▢ Name the code, then fix it without cloning and without changing what the program prints.

   let mut v = vec![1, 2, 3];
   let last = &v[v.len() - 1];
   v.push(4);
   println!("{last}");
   

3. ▢ Which code does each situation produce?

   • a) A for loop over a Vec by value, then using the Vec afterwards
   • b) Calling push on a binding declared without mut
   • c) Two &mut to the same value alive at once
   • d) Returning a reference to a local variable

4. ▢ Why does the first method compile and the second not?

   fn a(&mut self) {
       let name = &self.config.name;
       self.cache.insert(name);
   }
   
   fn b(&mut self) {
       let name = self.name();     // fn name(&self) -> &str
       self.cache.insert(name);
   }
   

5. ▢ A reviewer sees Rc<RefCell<Config>> in a pull request that was previously a plain Config. What should they ask?

Real-world reps

• [ ] Take each of the five error codes and write the smallest program that triggers it. Then run rustc --explain on each and compare your reproduction with the official one.
• [ ] Write the disjoint-fields example both ways, confirm which compiles, then fix the failing one three different ways and pick the one you would defend.
• [ ] Tomorrow: before compiling anything new, predict out loud whether it will be rejected and with which code. Keep score for a week. That score going up is the stage being finished.

Going further

• Rust Compiler Error Index: every code with a minimal reproduction
• E0382, E0499, E0502, E0505: the four this stage produces most
• Ownership and borrowing: the rules, the codes, and the fix-against-workaround table
• Learn Rust With Entirely Too Many Linked Lists: what happens when the structure genuinely fights ownership, which is stage 5
• Resources

Not landing? Reread the primary source at the top, since this lesson compresses it and compression is where understanding leaks. Check the glossary for any term that felt slippery.

If the lesson itself is unclear rather than the material, that is a defect: open an issue.