unused_assignments on MIR warns on earlier compound assignment in a read-modify-write chain

I tried this code:

fn main() {
    let mut a = 10.;
    let b = 13.;
    let c = 11.;

    a += b;
    a -= c;
}

I expected only the second assignment (a -= c) to trigger unused_assignments, matching old stable behavior (rustc 1.91.1 (ed61e7d 2025-11-07)).

The second compound assignment reads the previous value of a, so the value produced by a += b appears to be used as part of evaluating a -= c.

Instead, this happened:

warning: value assigned to `a` is never read
 --> /tmp/haha.rs:6:5
  |
6 |     a += b;
  |     ^^^^^^
  |
  = help: maybe it is overwritten before being read?

warning: value assigned to `a` is never read
 --> /tmp/haha.rs:7:5
  |
7 |     a -= c;
  |     ^^^^^^
  |
  = help: maybe it is overwritten before being read?

Find this when working on #154456

The question here is about the lint result itself: when a compound assignment is immediately followed by another compound assignment on the same place, should the earlier assignment still be considered "never read", even though the later operation reads the old value as part of its read-modify-write semantics?

corresponding test case:

rust/tests/ui/liveness/liveness-unused.rs

Lines 172 to 197 in ac40f5e

    
           fn f9() { 
        
               let mut a = 10; 
        
               //~^ ERROR variable `a` is assigned to, but never used 
        
               let b = 13; 
        
               let c = 13; 
        
               let d = 13; 
        
               let e = 13; 
        
               let f = 13; 
        
               let g = 13; 
        
               let h = 13; 
        
               a += b; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a -= c; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a *= d; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a /= e; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a |= f; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a &= g; 
        
               //~^ ERROR value assigned to `a` is never read 
        
               a %= h; 
        
               //~^ ERROR value assigned to `a` is never read 
        
           }

link #142390 for root cause.

@cjgillot

@cjgillot do you think this need to be fixed, since it is different behavior with old liveness check.

I tried different methods for it, first try to add a new field to track whether read old value:
main...chenyukang:rust:yukang-fix-154457-compound-assignment-liveness

it does not cover the code such as:

fn compound_assignment_after_branch_join(cond: bool) {
    let mut a = 0.0;
    let _ = a;

    if cond {
        a = 1.0;
    } else {
        a = 2.0;
    }

    a += 1.0;
    //~^ ERROR value assigned to `a` is never read
}

the second solution is more completed, but I guess there will also some perf regression: https://github.com/rust-lang/rust/pull/157066/changes

Navigation Menu

Repository navigation

unused_assignments on MIR warns on earlier compound assignment in a read-modify-write chain #154457

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	fn f9() {
	let mut a = 10;
	//~^ ERROR variable `a` is assigned to, but never used
	let b = 13;
	let c = 13;
	let d = 13;
	let e = 13;
	let f = 13;
	let g = 13;
	let h = 13;

	a += b;
	//~^ ERROR value assigned to `a` is never read
	a -= c;
	//~^ ERROR value assigned to `a` is never read
	a *= d;
	//~^ ERROR value assigned to `a` is never read
	a /= e;
	//~^ ERROR value assigned to `a` is never read
	a \|= f;
	//~^ ERROR value assigned to `a` is never read
	a &= g;
	//~^ ERROR value assigned to `a` is never read
	a %= h;
	//~^ ERROR value assigned to `a` is never read
	}

unused_assignments on MIR warns on earlier compound assignment in a read-modify-write chain #154457

Description

Activity

chenyukang commented on Mar 27, 2026

chenyukang commented on May 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions