Update imported Vars in the third pass

[ilevkivskyi]

Fixes #5275
Fixes #4498
Fixes #4442

This is a simple band-aid fix for Invalid type in import cycles where type aliases, named tuples, or typed dicts appear. Note that this is a partial fix that only fixes the Invalid type error when a type alias etc. appears in type context. This doesn't fix errors (e.g. Cannot determine type of X) that may appear if the type alias etc. appear in runtime context.

The motivation for partial fix is two-fold:

• The error often appears in stub files (especially for large libraries/frameworks) where we have more import cycles, but no runtime context at all.
• Ideally we should refactor semantic analysis to have deferred nodes, and process them in smaller passes when there is more info (like we do in type checking phase). But this is much harder since this requires a large refactoring. Also an alternative fix of updating node of every NameExpr and MemberExpr in third pass is costly from performance point of view, and still nontrivial.

[JukkaL]

Hmm I'm not sure if this fixes the problem in general. What if there are arbitrary references to the imported name that are bound during pass 2 in the module that contains the import -- I think that they don't necessarily get updated.

[JukkaL]

What if you have tp('x') in this file? Or reveal_type(tp)?

[ilevkivskyi]

Yes, this will not work. I was thinking about the Invalid type problem. All references in type context will be correctly re-resolved in the third pass. While there is no such thing as forward reference in runtime context.
I however still think this fix may have some value:

• We have seen many complains about Invalid type, but few complains about Cannot determine type (the error that appears if you try tp('x'))
• The reason for above fact is that many of the import cycle exist only for annotations, tp('x') will fail at runtime anyway
• This error quite often appears in stub files for large libraries, where we only care about type context

It is up to you of course.

[ilevkivskyi]

@JukkaL As you requested elsewhere I added a detailed doctring, tests for still not fixed behavior, and updated the PR description.

[JukkaL]

Thanks for the very clear docstrings! This looks good now (just left a few nits). Please try this with internal Dropbox codebases before merging, though.

[JukkaL]

Grammar nit: use lower case 'a' in 'are'.

[JukkaL]

'this a' -> 'this is a'

[JukkaL]

It would also be good to create a follow-up issue for the remaining problems, if one doesn't exist yet.

[ilevkivskyi]

It would also be good to create a follow-up issue for the remaining problems, if one doesn't exist yet.

It looks like an issue about Cannot determine type in import cycle was closed as solved
#2015, but the solution doesn't work with named tuples and typed dicts. I think I will open a new issue, and link the old one for more context.

[ilevkivskyi]

This causes one redundant cast and one real error (bad annotation).

[ilevkivskyi]

Appveyor failure looks like a flake.