Fix phpstan/phpstan#13440: Seemingly same type reports as invalid/incompatible.

[phpstan-bot]

Summary

Fixes a false positive where PHPStan reports "Parameter #2 $cb of class Box constructor expects Closure(Foo): TNewReturn, Closure(Foo): TNewReturn given" — the expected and given types are identical but flagged as incompatible due to an invariance check failure. This only occurs at level 9+ (checkExplicitMixed: true).

Changes

• Modified src/Type/Generic/TemplateTypeVariance.php — in the isValidVariance() method's invariant branch, added a fallback check: if equals() fails but both types are TemplateType instances with the same scope and name, treat them as equal
• Added tests/PHPStan/Rules/Classes/data/bug-13440.php — regression test data file
• Modified tests/PHPStan/Rules/Classes/InstantiationRuleTest.php — added checkExplicitMixed property and testBug13440() test method

Root cause

At level 9+, RuleLevelHelper::transformCommonType() converts TemplateMixedType to TemplateStrictMixedType (via toStrictMixedType()) to enforce stricter mixed type checking. This transformation preserves the template identity (name, scope, variance) but changes the concrete class.

The accepting type (constructor parameter) gets fully transformed, so TVal inside Closure(Foo<TVal>): TNewReturn becomes a TemplateStrictMixedType. However, transformAcceptedType() deliberately does NOT transform closure parameter types (for sound contravariance reasons), so the given type keeps TVal as TemplateMixedType.

When the invariance check in isValidVariance() compares these two template types using equals(), it fails because TemplateTypeTrait::equals() checks $type instanceof self — and TemplateMixedType is not an instance of TemplateStrictMixedType (or vice versa). The fix adds a secondary check: if both sides are TemplateType instances with the same scope and name, they represent the same template parameter and should pass the invariance check.

Test

Added a regression test that reproduces the issue: a generic class Box<TVal, TReturn> with a method that calls new self($this->val, $cb) where $cb is a closure with a generic type parameter Foo<TVal>. With checkExplicitMixed: true, this previously produced a false positive argument.type error.

Fixes phpstan/phpstan#13440

[VincentLanglet]

When dumping $a and $b the issue was kinda clear

string(44) "TVal of mixed (class Bug13440\Box, argument)"
string(44) "TVal of mixed (class Bug13440\Box, argument)"
string(38) "PHPStan\Type\Generic\TemplateMixedType"
string(44) "PHPStan\Type\Generic\TemplateStrictMixedType"

The second one was transformed into a strict type by the RuleLevelHelper but not the first one.
Callable/Closure was traversed by the transformAcceptedType but not the transformCommonType.

[staabm]

I think it makes sense. I am not generics expert though.

[VincentLanglet]

I don't think that's the right fix ; I'll open a new PR