Check code after inferred UninhabitedType

[ilevkivskyi]

Fixes #3994

Currently code after inferred UninhabitedType is silently skipped, for example no errors are shown in this code:

T = TypeVar('T')
def f(x: List[T]) -> T:
    ...

class C:
    x = f([])
    def m(self) -> str:
        return 42 # No error!

if bool():
    f([])
    1 + ''  # No error!

There are other scenarios in tests. With this PR errors are shown as expected, since UninhabitedTypes resulting from ambiguous inference don't influence binder.

[JukkaL]

Thanks for fixing this! It's important to fix false negatives, since we want users to be able to trust type checking results. I have just one small comment.

[JukkaL]

Also mention why we care about this and where this makes a difference.

[ilevkivskyi]

Also mention why we care about this and where this makes a difference.

I added a short discussion.

[JukkaL]

This generates a bunch of new errors in Dropbox internal codebases. Since this fixes false negatives, they may just be issues in our code, but I'll have to verify it.

[ilevkivskyi]

This generates a bunch of new errors in Dropbox internal codebases. Since this fixes false negatives, they may just be issues in our code, but I'll have to verify it.

I think this PR shouldn't bring anything false positive, but will be interested to see your findings.

[JukkaL]

This PR seems to cause an invalid type to be inferred for the following code:

from typing import Any

class C(dict):
    def f(self, x: Any) -> None:
        y = super(C, x).__new__(x)
        reveal_type(y)  # None, which is unexpected

Previously the reveal_type line was skipped. The underlying issue doesn't seem new though, and similar problems also happen on master.

This works unexpectedly also on master (even when using --strict-optional):

from typing import TypeVar

T = TypeVar('T')

def f() -> T: pass

x = f()
reveal_type(x)  # None

The issue seems rare enough that it doesn't block merging this, but it would be nice to at least understand what is going on.

[ilevkivskyi]

The issue seems rare enough that it doesn't block merging this, but it would be nice to at least understand what is going on.

I don't know if it is related or not, but I have seen some problems in meet.py with None and UninhabitedType. Another possible suspect is in partial None types, I remember looking at it recently I didn't really like how NoneTyp vs UninhabitedType is treated, I will check tomorrow morning if this can be fixed quickly, if not, then I propose to merge this and take a look at this problem later (you already opened an issue about this).

[JukkaL]

I have a potential fix in a local branch. I'll have a PR out tomorrow.

…

On Thu, Oct 12, 2017 at 21:02 Ivan Levkivskyi ***@***.***> wrote: The issue seems rare enough that it doesn't block merging this, but it would be nice to at least understand what is going on. I don't know if it is related or not, but I have seen some problems in meet.py with None and UninhabitedType. Another possible suspect is in partial None types, I remember looking at it recently I didn't really like how NoneTyp vs UninhabitedType is treated, I will check tomorrow morning if this can be fixed quickly, if not, then I propose to merge this and take a look at this problem later (you already opened an issue about this). — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#4059 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDnx_ZJ0XqTsAejW8GsFcyfyFFJKqS3ks5srnBZgaJpZM4PuPQV> .

[JukkaL]

Now that #4112 was merged, the motivating example generates an error (though not all errors that we'd like) so this seems a little less urgent now. I may postpone this until the next release.