unused_assignments on MIR warns on earlier compound assignment in a read-modify-write chain
@chenyukang is already working on this.
Since Mar 27, 2026.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
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 (ed61e7d7e 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 https://github.com/rust-lang/rust/pull/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: https://github.com/rust-lang/rust/blob/ac40f5e105ddc8144904679cb63c8879708a9a26/tests/ui/liveness/liveness-unused.rs#L172-L197
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.