Non-trivial results in mypy_primer are surprising. I know there is a bug in type_object_type() that when it is called before the constructor is processed we may get wrong result (e.g. because it is decorated) instead of deferring the current node. But I thought the way I implemented caching should not be affected by this bug. I will take a look today or tomorrow.

Although remaining errors are kind of correct, they are sill weird. It looks like they appear because previously

class C
    @no_type_check
    def __new__(cls): ...

resulted in Any as the type of C class object. But somehow it is now C in case of an import cycle. FWIW I can't reproduce this in a simple test.

OK, so it turns out there was an existing bug (inconsistency) with @no_type_check, where the decorated function was not Any for a brief period between semantic analysis and type checking. I simply fix that.

While looking at this I found second place where we don't handle not-ready types properly (decorated overloads), again I simply don't cache in this case, since a proper fix may be non-trivial (I also update the relevant TODO item). I update the PR description to mention this.

@sterliakov Of course there can be more. But those are all real bugs, we would need to fix them sooner or later anyway. In an ideal bug-free world, we should be able to always cache.

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅