Fix crash on nested generic callable

[ilevkivskyi]

Fixes #10244
Fixes #13515

This fixes only the crash part, I am going to fix also the embarrassing type variable clash in a separate PR, since it is completely unrelated issue.

The crash happens because solver can call is_suptype() on the constraint bounds, and those can contain <Erased>. Then if it is a generic callable type (e.g. def [S] (S) -> T when used as a context is erased to def [S] (S) -> <Erased>), is_subtype() will try unifying them, causing the crash when applying unified arguments.

My fix is to simply allow subtyping between callable types that contain <Erased>, we anyway allow checking subtpying between all other types with <Erased> components. And this technically can be useful, e.g. [T <: DerivedGen1[<Erased>], T <: DerivedGen2[<Erased>]] will be solved as T <: NonGenBase.

Btw this crash technically has nothing to do with dataclasses, but it looks like there is no other way in mypy to define a callable with generic callable as argument type, if I try:

def foo(x: Callable[[S], T]) -> T: ...

to repro the crash, mypy instead interprets foo as def [S, T] (x: Callable[[S], T]) -> T, i.e. the argument type is not generic. I also tried callback protocols, but they also don't repro the crash (at least I can't find a repro), because protocols use variance for subtyping, before actually checking member types.

[ilevkivskyi]

Oh, it looks like it (accidentally) fixes another crash: #13515

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[ilevkivskyi]

If there are no objections, I am going to merge this soon (this is a low risk fox for a crash).

[JukkaL]

Thanks!