Always create correct instances

[ilevkivskyi]

As discussed with @JukkaL in #3279 (comment) we should always create Instances with correct number of type arguments.

This PR makes named_type and other similar functions return correct instances. At the moment this discovered only two actual bugs (with namedtuple and Awaitable). Unfortunately, I could not turn on all the asserts and check for other possible problems, since most test fixtures do:

class tuple: pass
class dict: pass

[ilevkivskyi]

This PR revealed another bigger problem, most "synthetic" types are never visited in third pass, so that the type arguments stay incorrect. For example with NamedTuple:

class N(NamedTuple):
    x: int
    y: List

reveal_type(N(1, []).y)  # Revealed type is 'builtins.list'

The revealed type should be builtins.list[Any], the same applies to TypedDict and NewType.
Even worse, sometimes this can lead to crashes:

class N(NamedTuple):
    x: int
    y: List[int, str, Any]

reveal_type(N(1, []).y) # mypy crashes here with "IndexError: list index out of range"

I will play with this a bit, and if I will find a simple solution, then I will add it here.

[gvanrossum]

I will play with this a bit, and if I will find a simple solution, then I will add it here.

Thank you! If you don't, we should have an issue to track it.

[ilevkivskyi]

@gvanrossum It looks like the issue with synthetic types I mentioned above is a bit bigger than I thought, so that I would prefer to make a separate additional PR. Do you have comments on this PR?

[JukkaL]

The fixtures using class tuple: ... etc. should be fixed to use generic classes (no need to do it here though). It shouldn't be hard, at least unless some tests expect them to not be generic.

[gvanrossum]

You can add the comment and merge!

[gvanrossum]

This is an Aha! that deserves a comment!

[JukkaL]

We can't use type joins safely during semantic analysis, since MROs may be incomplete :-(

One potential way to fix this would be to postpone all joins to a new, fourth semantic analysis pass. That sounds risky though, so for the 0.510 release we could just use Any here as the fallback as a temporary workaround.

This has happened so many times that I've been considering asserting during joins and other type operations that need MROs that they aren't called during semantic analysis, at least when running tests.

[ilevkivskyi]

One potential way to fix this would be to postpone all joins to a new, fourth semantic analysis pass.

I just did this in third pass. It seems to work OK. This also solves other crashes, see my comment
#3315 (comment) (I will add tests and make a PR this evening).

But I think you should do whatever you think is safest for the release. So maybe Any is a good workaround.

[JukkaL]

I just did this in third pass. It seems to work OK. This also solves other crashes, see my comment
#3315 (comment) (I will add tests and make a PR this evening).

We recompute some MROs in the third pass so they could still be incomplete in the middle of the third pass.