Helping hand from order of messages: causes and consequences

[Hibou57]

Is your feature request related to a problem? Please describe.

When there are lot of error messages, like in a refactoring attempt, the order of messages is important.

A sample case for illustration:

def main() -> None:
    a = b()

b is not defined, so obviously it is wrong and the real issue is there.

PyRight shows it as:

test.py
  test.py:2:5 - error: Type of "a" is unknown (reportUnknownVariableType)
  test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
  test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
3 errors, 0 warnings, 0 informations

I know it's not easy: the cause or the consequence first? An error is a consequence, so it may seems obvious consequences are to comes first. But since a cause can have multiple consequences, to designate the cause first may be a better helping diagnostic. This make me think or syntactic error, where a single missing parenthesis in a file, can ends into a lon-long list of error messages. I always though it would be better to stop at the first, since it is expected this single error will produce many consequent errors. This behavior depends on the type of error and the amount and scope of the consequences they can have.

From a practical point of view, even Python agrees the first issue is something being not defined.

With this:

A = b()

It complains:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test.py", line 1, in <module>
    A = b()
        ^
NameError: name 'b' is not defined

This is why, for each module, I do an import check before the type-check.

Also, what can be inferred from something which simply does not exist? Or, is it relevant?

Describe the solution you’d like

The log could be instead like this:

test.py
  test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
  test.py:2:5 - error: Type of "a" is unknown (reportUnknownVariableType)
  test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
3 errors, 0 warnings, 0 informations

Or even better:

test.py
  test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
    this have 1 cascading consequence(s)
  test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
2 errors, 0 warnings, 0 informations

The fact something is finally not used, can be an indication solving an error about it is trivial, just removing it. It could come first. But this is more heuristic than formal, this may even be more expected from a linter than a type-checker. Opinions vary about it. Still, what about listing it as:

test.py
  unused entities:
    test.py:2:5: a
  test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
    this have 1 cascading consequence(s)
2 errors, 0 warnings, 0 informations

This is not an erroneous behavior, this is about clearer view when there a a lot of messages, unlike with this example.

But I don’t consider it as a bug, still thanks for PyRight.