Could you more clearly annotate which position you expect and which position you got?

Eg do this

let x = 1
//  ^ error here

You said you expect 1:1 which means line 1 column 1 which is clearly wrong because that would suggest you want the function keyword underlined in your example code.

@bradzacher Sorry, I updated my comment

@bachorp theres only 7 lines in your example. So 9:1 doesn't make much more sense.

As per my last comment (I edited after you saw it I think) could you annotate your example code with comments showing the actual and expected locations?

@bradzacher Done

The rule is actually right here

let x = null

In this code the variable x is not used.

let x = null
foo(x)

In this code the variable x is used after it is assigned a value.

let x = null
foo(x)
x = 1 // error on this line

In this code you will have an error as the last line assigns a value to x which is never used.

Putting these together:

    let x = null

    x = foo(x)
//          ^ usage of the declaration ✅
//  ^ new assignment to x which is never used  ❌

@bradzacher Can you please clarify at which position we would expect the error? If I understand your example correctly (we expect an error at ❌ but not at ✅), the rule is not right here.

Ah - I see the bug now.
Yes, our rule is showing the wrong error and does not match the base rule

https://typescript-eslint.io/play/#ts=4.6.2&sourceType=module&code=PQKgBApgzgNglgOwC5gQewLQFcFahAEwwDcBDAJygC5Jzy1ywRgAoUSWRFAASQE8ADtADG5OAKQZo8ZMHTZc+ImUo0IdBk1YsAZjmFI4aBGB1o0ACgAeASjABvFmGdhyEJFnImrLAL4sWGHcwKzAAXlQsGBgA0IizS1sgA&rules=N4XyA&tsConfig=N4XyA

there actually seem to be additional issues, and some of test seem to be incorrect,

interface Foo {
  bar: string;
  baz: Foo['bar'];
  //   ^ reports this
}

@armano2 - that's the same issue - we're reporting the last read instead of the last write.

I don't think we ever merged this from upstream: eslint/eslint@5df5e4a

Separately there are the following commits we should assess and merge in as well:

• eslint/eslint@9e9b5e0
• eslint/eslint@f110926
• eslint/eslint@800bd25
• eslint/eslint@f364d47

@bradzacher correct, we do not have those changes / our rule is not reporting on them correctly, do you mind filling separate issue about this?

I also didn't realise that this was a duplicate of #3311 oops