Non-trivial results inmypy_primer are surprising. I know there is a bug intype_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

classC@no_type_checkdef__new__(cls): ...

resulted inAny as the type ofC class object. But somehow it is nowC 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 notAny 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 toalways cache.

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