Why report entire functions as an error on "missing return statement"

If mypy --show-column-numbers --show-error-end thinks a function is missing a return statement, the entire function is the error. This is also the case for note: <something> defined here which appears, for example, when you call a function with the wrong arguments.

I think one could argue that reporting the entire function as the location of the note/error is not more helpful than, for example, reporting just the function signature (or even just the function name) as the error range.

It's not as much an issue when looking at command line output, but more visual tools (e.g. VSCode) use --show-column-numbers --show-error-end to highlight errors. This results in entire functions being highlighted, which is very invasive and makes it hard to work, for example, if mypy runs while I'm in the middle of writing a function, and the entire region I'm typing in is suddenly alarmingly red.

Comments are not included as part of the error if they are at the end of the function-in-progress, which makes sense, but then, if the point is to show that the problem is "anywhere in this block of code", you could argue an indented comment should probably be included.

I tried to argue that this is a visualization problem on the editor's side, but they argue back that they don't want to interpret your output in specific cases and thus have to chase changes you make, which is also valid.

Is there a real need to report entire functions as a problem or a note?

(An example of how VSCode shows this)

Start by reproducing the missing-return and “defined here” diagnostics with --show-column-numbers and --show-error-end, then inspect how their ranges appear in VSCode. Compare function-wide, signature-only, and name-only ranges, including comments at the end of an unfinished function; done means reaching and testing a clear decision about the diagnostic span.