Don't emit "value assigned to ... is never read" for each instance?

[mqudsi]

Scrolling through warnings when compiling projects during the early development stages can be a bit of a chore, but there's not much the compiler can do about it as it doesn't know whether you just haven't gotten around to something or if you forgot about it. I typically add #![allow(unused_code)] and #![allow(dead_code)] to new projects and take them out when the codebase nears completion of v1, but it occurs to me that there's no real value in emitting repeated warnings for unused assignments of the same variable.

e.g.

There are different heuristics here depending on how important it is to generate all warnings in advance, including

• a bloom filter for the variable (by ast path, not name) with the corresponding buckets filled when the first warning is emitted

This means code like

{
    let foo = bar;
    let foo = bar;
}

continues to emit two warnings as they are two different variables being unread, but this wouldn't emit two warnings:

{ 
    let mut foo = "bar";
    foo = "baz";
}

as we are deduplicating by variable and not by unread write so only the first assignment will generate the warning, which is probably ok since addressing that error by adding either of

{
    let mut foo = "bar";
    if (foo == "bar") { ... }
    foo = "baz";
}

or

{
    let mut foo = "bar";
    foo = "baz";
    if (foo == "bar") { ... }
}

will go back to generating the warning for the other instance of unused write.

• actually tracking individual code paths for each variable and only warning for writes that are not provably exclusive:

{ 
    let mut foo = "bar";
    foo = "baz";
}

The above would continue to generate two warnings, but the following would generate only one:

let mut bar;
let foo = "hello";
match foo {
    "bar" => foo = "bar",
    "baz" => foo = "qux",
}

as no value was overwritten at any point and a single read would suffice to address both instances of unused writes.

Personally, I think the latter is overkill and might slow things down and increase memory usage in the compiler without much benefit. The former is both fast and easy (with no allocations and predetermined memory consumption based off the size of the bloom filter).

[mqudsi]

In the case of multiple unread writes to an immutable variable, there are no drawbacks to approach number one as they are necessarily exclusive.