Repository navigation
Print source line with error and underline target of error #7411
Description
Now that mypy can usually report the column number of errors in a useful manner, we could print out the contents of the source line for each error and underline the token the error points to (based on line/column information). This can be either enabled by default or through a flag -- I'm not sure which option I'd prefer yet.
Arguments for doing this:
- This makes it easier to see what is wrong, especially if the error message happens to be terse, or if there is a lot of things going on in a single line.
- Consistency with Python: Python tracebacks show the source line.
- Not everybody has configured their editor to highlight the location of the error.
- If a user edits the file with the error, the line number will get out of alignment. Having the source line in the output makes it easier to see where the error points to even if there have been edits.
- Many other tools can do this, so many users are used to this behavior.
Arguments for not doing this (at least by default):
- The length of mypy output is increased significantly. If we show a source line and a separate line with underlining, the number of lines may increase by a factor of three.
- The output may be harder to scan or look noisy, since there will be more stuff. Using colors should help with this (Use colors in mypy output #7410).
- If the reported line/column number is not logically correct, this may be confusing. We may want to fix the line/column numbers of most errors first. (I've already done some of this relatively recently.)
Thoughts?
Activity
ilevkivskyi commentedon Aug 29, 2019
I think reporting reliably correct line/column numbers is a blocker for this. And it is still not perfect unfortunately.
Also
end_linenoandend_col_offsetwill simplify finding better spans, but they are Python 3.8+ only (there is even nice helper).gvanrossum commentedon Aug 29, 2019
Well, even if it only shows the line that can sometimes help (e.g. if you're looking at slightly stale mypy output and have trouble matching up the line number with the actual source line in your editor). So I'm not so hung up on correct column numbers as Ivan. Having this will probably motivate users to report cases where the column number (or even the line number) is off.
I would not like this by default, because I often look at long lists of mypy errors where it would just be noise, and in an Emacs
*compilation*buffer going to the corresponding line is easy.Interestingly, this is an area where compilers and linters seem to differ -- I know of no linter that shows the text of the line (at least not by default), while all compilers I know of do that. I think mypy is still more like a linter than like a compiler (mypyc notwithstanding :-).
Also, let's not get into bikeshedding. Let's just do it.
ilevkivskyi commentedon Aug 31, 2019
I have played with this a bit and I think I have got a decent readability with help of colors and word-wrap in errors. I would however still make this optional, since the output is quite massive and as you can see even in this small sample columns are not ideal. I will make a PR later today.
gvanrossum commentedon Aug 31, 2019
I am not near a laptop, but don’t gcc/clang show the offending line before the error message?
gvanrossum commentedon Aug 31, 2019
Scratch that, I just checked and it also prints the message before the text of the line. I guess I was thinking of Python's
SyntaxErrorformatting.JukkaL commentedon Sep 2, 2019
I think that we should fix at least the most obvious problems with column numbers before documenting this as a feature. I have a half-finished PR that fixes column numbers of arguments and may be able to finish that up soon. Also, assignments should probably point to the rvalue.
Other comments:
foo.barinfoo.bar.zar).