Invalid "variable does not need to be mutable" warning in 2018 edition with partially initialized structs

[LunaBorowska]

fn main() {
    let mut s: (i32, i32);
    s.0 = 3;
    s.1 = 4;
    println!("{} {}", s.0, s.1);
}

Causes the following warning:

warning: variable does not need to be mutable
 --> src/main.rs:2:9
  |
2 |     let mut s: (i32, i32);
  |         ----^
  |         |
  |         help: remove this `mut`
  |
  = note: #[warn(unused_mut)] on by default

Removing mut causes an error:

error[E0594]: cannot assign to `s.0`, as `s` is not declared as mutable
 --> src/main.rs:3:5
  |
2 |     let s: (i32, i32);
  |         - help: consider changing this to be mutable: `mut s`
3 |     s.0 = 3;
  |     ^^^^^^^ cannot assign

error[E0594]: cannot assign to `s.1`, as `s` is not declared as mutable
 --> src/main.rs:4:5
  |
2 |     let s: (i32, i32);
  |         - help: consider changing this to be mutable: `mut s`
3 |     s.0 = 3;
4 |     s.1 = 4;
  |     ^^^^^^^ cannot assign

error: aborting due to 2 previous errors

Tested on nightly on the playground. This code is stupid, but I don't think it should report "unused mut" warnings.

[eddyb]

I think the error (that partial initialization requires mut) is wrong, or at least surprising.
cc @nikomatsakis @pnkfelix

[nikomatsakis]

So, we decided to echo existing borrowck behavior here, which does require a mut for.. no particularly good reason (this is #21232, a long-standing issue). I did this as a performance optimization in #53258 with the intention that we would expand the handling of immutable variables at some later point.

The simplest thing would be to update the "mut checker" to understand this limitation, I suppose. The more complex thing would be to try and fix #21232 — this feels like something we might consider, as NLL is reaching a decent point.

[nikomatsakis]

In terms of how to suppress the false warning, here are a few tips:

The BorrowCheckContext has a field used_muts indicating the variables and things where a mut declaration was *required::

rust/src/librustc_mir/borrow_check/mod.rs

Lines 436 to 438 in c9865b1

	/// This field keeps track of all the local variables that are declared mut and are mutated.
	/// Used for the warning issued by an unused mutable local variable.
	used_mut: FxHashSet<Local>,

So we probably need to add something to that set when we see a.b = c. That is a MIR assignment, so it winds up invoking mutate_place:

rust/src/librustc_mir/borrow_check/mod.rs

Lines 493 to 499 in c9865b1

	self.mutate_place(
	ContextKind::AssignLhs.new(location),
	(lhs, span),
	Shallow(None),
	JustWrite,
	flow_state,
	);

Here we special case out assignments to immutable local variables (not this case):

rust/src/librustc_mir/borrow_check/mod.rs

Lines 1094 to 1108 in c9865b1

	// Special case: you can assign a immutable local variable
	// (e.g., `x = ...`) so long as it has never been initialized
	// before (at this point in the flow).
	if let &Place::Local(local) = place_span.0 {
	if let Mutability::Not = self.mir.local_decls[local].mutability {
	// check for reassignments to immutable local variables
	self.check_if_reassignment_to_immutable_state(
	context,
	local,
	place_span,
	flow_state,
	);
	return;
	}
	}

and then fall through to access_place:

rust/src/librustc_mir/borrow_check/mod.rs

Lines 1110 to 1117 in c9865b1

	// Otherwise, use the normal access permission rules.
	self.access_place(
	context,
	place_span,
	(kind, Write(WriteKind::Mutate)),
	LocalMutationIsAllowed::No,
	flow_state,
	);

Something in there must be failing to update used_muts...

[nikomatsakis]

@xfix out of curiosity, how did you notice this bug? Are you relying on the current behavior of being able to assign to (but not read from) a field of an uninitialized variable?

[LunaBorowska]

@nikomatsakis I just like abusing compiler edge cases hoping to find bugs, this isn't from an actual program.