Fix crash when annotating callable definition location

[miedzinski]

Fixes #3362.

[miedzinski]

I have no idea how to add test case for this.

[case testUnexpectedKwargsDefinedHere]
import m
m.A(x=1)  # E: Unexpected keyword argument "x" for "A"
[file m.py]
class A:
    def __init__(self) -> None:  # N: "A" defined here
        pass

doesn't trigger note, because typ.definition.fullname() returns None.

[ilevkivskyi]

@miedzinski
I have found what is the problem. The _fulname attribute of function definition is not set in first pass for methods, since methods are not visited during the first pass. I added this code:

            if not defn._fullname:
                defn._fullname = self.qualified_name(defn.name())

in visit_func_def of second pass on line 330 and it works:

tst22.py:21: error: Unexpected keyword argument "example" for "Popen"
/usr/local/lib/mypy/typeshed/stdlib/3/subprocess.pyi:276: note: "Popen" defined here

(also works with your test example above).

[miedzinski]

Do you want me to include it with this patch or would you like to submit it yourself?

[ilevkivskyi]

Do you want me to include it with this patch

Yes.

[ilevkivskyi]

And tests

[ilevkivskyi]

Thanks! Looks good to me.

[gvanrossum]

I just received a spurious message of the form

/Users/guido/src/mypy/typeshed/stdlib/3/builtins.pyi:594: note: "sort" of "list" defined here

The code to issue this message was modified by this PR.

I have not been able to repro this "in the lab" yet (the above was part of a huge run on internal code), but I suspect that this might be related to an error in another file that was ignored by # type: ignore in some other file. The fix would be to somehow check whether the fail() call actually caused an error to be generated or not. (That would require some surgery to get the error machinery to return that information -- several methods would have to pass this info back reliably.)

[pkch]

I don't have a specific solution proposal yet, but a very similar issue came up in my discussions with @ilinum about how to do #3141 more reliably: it would have helped if the error engine was more knowledgeable.

[gvanrossum]

I also noticed that the spurious note seems to only appear with a cold -i cache. This may be a different problem with the same code -- finding the module may fail if the module was read from the cache.

[ilevkivskyi]

I would propose an alternative solution. We could report the note on the same line as error, but report the source in the note itself, something like:

test.py: 16: error: Incompatible something ...
test.py: 16: note: "something" defined in /some/other/file on line 144

Adding # type: ignore will silence both the error and the note. This solution will have one important additional benefit: there is an issue to sort errors by file, and after sorting all errors, the error and the note may be far apart from each other, which would be weird. With this solution they will be always together.

(TBH, this wording also seems nicer to me than the current one.)

[gvanrossum]

Finally it may be the case that what I saw was due to some filtering script we have that black-lists certain files. (But the -i issue is still separate -- even if this PR did not change the behavior here.)

[miedzinski]

Already said that on gitter: this is might have been introduced in this patch, mainly because of fix @ilevkivskyi proposed. Earlier methods lacked fullnames during 2nd pass, so the note wasn't triggered.

[gvanrossum]

A downside to @ilevkivskyi's solution is that I can't hit Enter in the Emacs *compilation* window to go to the definition.