Report if unused var was mutated but not read

[ViveLeQuebec]

Compiler version

3.7.2

Minimized code

trait Test {
  def incr(): Unit
}

object Test {
  val test = new Test {
    var position: Int = 0

    def incr(): Unit = { position += 1 }
  }
}

Output

[warn] -- [E198] Unused Symbol Warning: Test.scala:9:8 
[warn] 9 |    var position: Int = 0
[warn]   |        ^^^^^^^^^^
[warn]   |        unused private member

Expectation

Compiles without warnings.

[Gedochao]

Last good release: 3.7.0-RC1-bin-20250307-977232c-NIGHTLY
First bad release: 3.7.0-RC1-bin-20250308-133dcb3-NIGHTLY
c880a58 is the first bad commit (#22729)
cc @som-snytt

[som-snytt]

It's a bit of a philosophical question, as the var is only assigned to.

However, myvar = myvar + 1 does not warn, because obviously myvar is read.

I can probably whack this mole and make it not warn, but is that correct from a feature standpoint?

(Under the hood, the LHS of the assignment is tagged as "target of assignment"; that tree is visited twice, on both the left and right sides of the Assign, seen both times as "target of assignment".)

At the surface level, the var is assigned but not read. (+= is an assignment operator.)

Note that "read but not assigned" has a distinct warning, but "assigned but not read" does not.

Also noting that this is not specific to anon classes, and it always worked this way.

About the message itself, this warns "not used" and not "assigned but not read".

class C:
  private var myvar: Int = 0
  def mine: Int =
    myvar = 42
    27

I don't know that tweaking the message is clarifying for either case (plain assignment or incrementing assignment).

Noting that the spec doesn't necessarily help, since there is not an equivalence of x += e and x = x + e because the x term is (obviously) only evaluated once.

I'll leave the ticket open to stew a bit, now that I've refreshed my memory about the mechanism.

[som-snytt]

I'm inclined to update the message, since terms such as "usage" or "reference" are used loosely. The language itself doesn't cope well with vars and overrides, etc, despite the illusion of precision in the terms getters and setters.

I think with adequate tracking of mutable vars, it is safe to make fine distinctions in the message text, where that is possible.

Here is a related ticket that was merged in 3.7.3; it illustrates some of the subtlety

#23200

There is further commentary on the PR but I haven't re-read my thinking from last spring yet:

#23211

[som-snytt]

The PR improves the message but does not attempt to warn about the explicit x = e(x) case, where the only read of x is to mutate x. Worth noting that just updating can have visible effects (memory, locks). Maybe a future lint pertains to capabilities.