[red-knot] add `Type::SubclassOf` support to `Type::try_call`

[carljm]

Description

Existing type checkers (and the typing spec) allow calling an object of type type[C] (in red-knot, Type::SubclassOf(<Class C>)), with the result of the call being an object of type C (in red-knot, Type::Instance(<Class C>)).

This is not actually sound, because Liskov compatibility is not enforced on type constructor methods (__init__ and __new__) when subclassing, so you can't be sure that a constructor call that works for a class C will actually work for a subclass of C. But it's widely relied on, and we will have to support it.

I would like to have an opt-in diagnostic emitted whenever you call an object of type[C], so users who want to avoid this unsoundness have that option.

[carljm]

On second thought, it may be best to hold off on this issue (or at least the new-diagnostic part of it) until after @AlexWaygood completes an in-progress refactor of CallOutcome, since this diagnostic would likely imply adding a new outcome variant to CallOutcome?

[mishamsk]

I can take it whenever @AlexWaygood is ready since I've triggered the issue in the first place. Not sure how you manage blocked issues, but feel free to assign this one to me and I'll monitor the comments

[mishamsk]

@AlexWaygood I believe this one is unblocked now? Also see another comment related to analyzing __init__ signatures for class literals:

// TODO annotated return type on `__new__` or metaclass `__call__`
            // TODO check call vs signatures of `__new__` and/or `__init__`

which may or may not be tackled together...

[AlexWaygood]

@AlexWaygood I believe this one is unblocked now?

Should be, yup!

Those other todos should be tackled in separate PRs, I think; they're pretty separate issues

[sharkdp]

The core functionality was added in #16597, but the diagnostic has not been implemented. Also, those calls will really only be properly checked when astral-sh/ty#186 is also implemented.

[mishamsk]

I think the full implementation of the Subclass arm will be pretty involved, but may be out of scope here. I was going to ask related question this week.

What I was thinking about is Self. When we handle plain class literals (#16511 case) we can avoid properly handling Self since class.to_instance() will return the correct type in all realistic scenarios. But with type[C], in ideal world we would record a stronger typing relationship - due to the free type variable... so fully model this:

T = TypeVar("T", bound="Base")

class Base:
    pass

class Sub(Base):
    pass

def get_instance(clz: type[T]) -> T:
    return clz()

instance = get_instance(Sub)
reveal_type(instance) # Sub, not Base

but for constructors.

and AFAIK there is no machinery for that currently.

Anyways, that's for the future. I hope I'll close astral-sh/ty#186 this week, and we can decide whether it makes sense to do a small PR to add the diagnostic here or dive into Self support