no-unused-vars should warn on the offending assignment instead of declaration

Tell us about your environment

• ESLint Version: v6.8.0 via eslint.org/demo

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration: default

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint. Simple example (from some actual immediate-mode UI code that takes in a y position and returns a height of what was rendered).

function print(v) {
  console.log(v);
  return 1;
}
let y = 1;
y += print(y);
y += print(y);
y += print(y);

eslint.org/demo#…

What did you expect to happen? No error, or, potentially an error on the first unused assignment: 8:1 - 'y' is assigned a value but never used. (no-unused-vars)

What actually happened? Please include the actual, raw output from ESLint. 5:5 - 'y' is assigned a value but never used. (no-unused-vars)

Are you willing to submit a pull request to fix this bug? Probably not, but potentially.

Edits: Title was previously “no-unused-vars erroneously fails if a line both uses and modifies a value via increment”, and I was confused by the error being on the declaration of y instead of the last (actually unused) assignment.

[gabrieldrs]

Although it reports the error at line 5, the actual error seems to occur because in your last line you assign a value to y but don’t use it. If you replace your last line with print(y); the error goes away.

I think this is the expected behaviour, isn’t it?

[Jimbly]

The inherent problem is the code is actually detecting the variable as completely unused (it’s treating x = f(x) as syntactically equivalent to x++), I think it might just be better to fix the code to consider that “used” (error message would completely go away, just like in let x=1; f(x); x = f(x);. The most "correct’ error message when your code looks like let x = 1; x=x+1; would be something like 'x' is assigned a value but only ever assigned back to itself, but that’s not even correct in the x=f(x) case. If you can figure out how to differentiate those cases inside of the isSelfReference logic in order to display a different error message, you could just fix the bug =)