Allow returning inferred None from functions

[ilevkivskyi]

Fixes #4214

As discussed in the issue, assigning an inferred (from generics, overloads, or lambdas) None type should be always allowed, while prohibiting assigning function calls that have an explicit None return type may have some value (at least people don't complain much about this).

Note: this error is quite nasty for dataclasses, where it flags a legitimate typical use case (see tests).

[JukkaL]

Using NoneTyp attribute to handle an edge case such as this seems like an overkill. This increases complexity and adds some overhead with a pretty small gain.

Instead, I'd rather rewrite the None return check to look at whether the callable refers to something with an explicit declared None return type (look for the annotation in the node, not the inferred type). It's fine if the semantics of the check change slightly as this is not required for correctness.

[ilevkivskyi]

OK, I have rewritten it without a flag and I like the new semantics even more, it looks more consistent.

This however required fixing an unrelated issue: previously all Vars at global and local scopes were unconditionally marked as inferred, this is a one line fix however, so I don't want to make a separate PR for this.

[JukkaL]

Thanks for the update, I like how the new check works. There seems to be a problem with methods though (see my comment).

[JukkaL]

I think that this should still generate an error, since A.g has an explicit None return type.

[JukkaL]

It would be okay for this to still generate an error, since __call__ has an explicit None return, but since this is an edge case it's not that important. Might be worth adding an issues about this though.

[ilevkivskyi]

@JukkaL
Yes, makes sense, I added some more special-casing. I would however avoid further special-casing as this is (as you mentioned before) not required for correctness.

[JukkaL]

I think that this is enough special casing for now. Looks good now!

[msullivan]

This seems to have introduced a regression where we will emit the Function does not return a value error message inside of functions that shouldn't be type checked:

def foo() -> None:
    pass

def lol():
    x = foo()

produces an error

[ilevkivskyi]

Hm, interesting, I will check this.