On second thought maybe it should be it's own rule, with in the bleeding edge. Because Psalm version of the tag is already in use. I'll change it.

I think it's not necessary, it's going to be really rare. I've also enabled conditional return types related rules for everyone :)

Some ideas (I haven't seen the code yet):

• This feature will allow us to usefully interpret static<T, U, V>. Because without consistent templates, we cannot assume how @template tags look above all child classes, but with consistent templates enforced, we can. So this should definitely be part of this PR. Try to have a method marked with generic static<...> tag, call the method on a subclass, it should result in SubClass<T, U, V>.
• There could be a new rule (this one is definitely for bleeding edge) - if someone uses generic static<...> in their code, we should tell them they need @phpstan-consistent-templates above the class. The easiest way to do this is to incorporate the logic in IncompatiblePhpDocTypeRule.

This feature will allow us to usefully interpret static<T, U, V>. Because without consistent templates, we cannot assume how @template tags look above all child classes, but with consistent templates enforced, we can. So this should definitely be part of this PR. Try to have a method marked with generic static<...> tag, call the method on a subclass, it should result in SubClass<T, U, V>.

Yes, that's the goal from phpstan/phpstan#5512 I was planning to do that in another PR. But sure it can be part of this one.

There could be a new rule (this one is definitely for bleeding edge) - if someone uses generic static<...> in their code, we should tell them they need @phpstan-consistent-templates above the class. The easiest way to do this is to incorporate the logic in IncompatiblePhpDocTypeRule.

If the logic will be in IncompatiblePhpDocTypeRule it's not gonna be a new rule, is it? Do you mean have a parameter for bleeding edge toggle, and do the checks according to that?

Yes, I often add a boolean parameter in bleedingEdge that changes behaviour of existing rules 😊

But if you find the implementation inelegant, certainly feel free to implement it in a separate rule. For one, it only applies to methods in classes and not functions, so IncompatiblePhpDocTypeRule might not be great after all.

I added a commit to correctly infer static<...> types, if the class has the tag. I think static<...> only makes sense for return types. So I didn't add it to property or method argument types. And about that, should IncompatiblePhpDocTypeRule give error if someone uses static<..> in property or argument? (that's a separate PR)

I'll implement the second part about the IncompatiblePhpDocTypeRule later.

Some ideas about validating static<...> I got meanwhile

• I'm not sure about IncompatiblePhpDocTypeRule anymore
• Because we should also validate that the stuff inside static<...> is correct, and the best place to do that is GenericObjectTypeCheck.
• So I imagine this is what should be done:

1. If @phpstan-consistent-templates is present above the class, validate the inner types of static<...> to see if they match @template above the class (in both bleeding edge and without bleeding edge).
2. If @phpstan-consistent-templates is not present, by default don't do anything.
3. If @phpstan-consistent-templates is not present, in bleeding edge it should be reported to add @phpstan-consistent-templates.

It's funny a little because one of the places where GenericObjectTypeCheck is called from is IncompatiblePhpDocTypeRule :) So I guess the changes should be tested in IncompatiblePhpDocTypeRuleTest by writing some new sample classes.

The current problem I'm having is that static<...> return type tag is already resolved to GenericObjectType when docblock is resolved in IncompatiblePhpDocTypeRule Should I inspect the $docComment->getText() to figure out if static<...> is used? Do you have any idea of the top of your head?

@canvural Yeah, I realized that we might need a new GenericStaticObjectType for this so that the information is kept when going out from TypeNodeResolver::resolveGenericTypeNode().

Same as GenericObjectType extends ObjectType, GenericStaticObjectType should extend StaticType.

It's also useful because we should be able to validate that static<X, Y> is truly returned from a method that typehints @return static<X, Y>.

static works by preserving StaticType when we're inside the class and work mainly with $this, but is converted to the final type (specific subclass) when a method is called from the outside.

The hardest part is going to be to figure out the correct relationships between ObjectType, StaticType, GenericObjectType, GenericStaticType when asked about isSuperTypeOf() about each other. But there's already some precedens about this from the current types.