Do not let method_exists() check fall through to general logic when object type contains template types

[phpstan-bot]

Summary

When using method_exists() on a template type narrowed to object&T (e.g., after an is_object() check), PHPStan incorrectly reports "will always evaluate to true". This is a false positive because an arbitrary object&T does not necessarily have any given method.

Changes

• Added an early return null in src/Rules/Comparison/ImpossibleCheckTypeHelper.php at the end of the method_exists specific handling block, when the object type contains template or late-resolvable types
• Added regression test in tests/PHPStan/Rules/Comparison/data/bug-8217.php reproducing the exact scenario from the issue
• Added test method testBug8217() in tests/PHPStan/Rules/Comparison/ImpossibleCheckTypeFunctionCallRuleTest.php

Root cause

The method_exists specific handling in ImpossibleCheckTypeHelper has checks for:

1. Concrete class names (getObjectClassNames() !== []) — checks hasMethod() directly
2. GenericClassStringType — checks on the generic type

For object&T where T is a bare template type, neither check applies (no class names, no GenericClassStringType), so the code falls through to the general type specifier logic. The general logic uses HasMethodType::isSuperTypeOf(), which calls $type->hasMethod() on the argument. For IntersectionType([ObjectWithoutClassType, TemplateMixedType]), hasMethod() returns Yes because TemplateMixedType inherits MixedType::hasMethod() which always returns Yes. This causes the general logic to conclude the check "will always evaluate to true".

The fix adds an explicit return null when the object type contains template or late-resolvable types, correctly indicating that method existence is uncertain.

Analogous cases investigated

• property_exists: Not affected — PropertyExistsTypeSpecifyingExtension returns empty SpecifiedTypes when finding a non-native property (which MixedType provides), so the general logic has nothing to check
• is_callable: Not affected — tested with is_callable($object) on object&T, no false positive
• class-string<T> templates: Not affected — handled correctly by the existing GenericClassStringType block in the specific method_exists handling
• T of object bound: Not affected — TemplateObjectWithoutClassType::hasMethod() correctly returns Maybe (via ObjectTypeTrait), not Yes

Test

Regression test reproduces the exact scenario from the issue: a function with @template T parameter, narrowed via is_object($object), then checked with method_exists($object, 'method'). The test expects no errors (previously reported a false positive).

Fixes phpstan/phpstan#8217

[VincentLanglet]

If the issue seems related to TemplateMixedType, why it doesn't currently occur for MixedType ?

[phpstan-bot]

Pushed. Here's the answer to the reviewer's question:

Why doesn't MixedType trigger the same false positive?

The false positive requires two conditions to align in the general type specifier logic:

1. ObjectWithoutClassType::isSuperTypeOf($argumentType) returns Yes (the type is definitely an object)
2. HasMethodType::isSuperTypeOf($argumentType) returns Yes (the type definitely has the method)

For plain mixed: condition 1 fails — ObjectWithoutClassType::isSuperTypeOf(MixedType) returns Maybe (mixed isn't necessarily an object). So the overall result is Maybe, no false positive.

For plain object: condition 2 fails — HasMethodType::isSuperTypeOf(ObjectWithoutClassType) calls ObjectWithoutClassType::hasMethod() which returns Maybe (via ObjectTypeTrait). So the overall result is Maybe, no false positive.

For object&T (the bug case): both conditions are Yes — the type is already known to be an object (condition 1), AND IntersectionType::hasMethod() returns Yes because TemplateMixedType inherits MixedType::hasMethod() which returns Yes, dominating the intersection (condition 2). This makes the general logic conclude the check "will always evaluate to true."

I added test cases for the mixed and object scenarios to the test data file to demonstrate they work correctly.

[VincentLanglet]

Should/could the fix be done in the general specifier ?

[phpstan-bot]

Done. The fix now addresses the reviewer's suggestion: instead of working around the issue in ImpossibleCheckTypeHelper, the fix is at the type system level by overriding hasMethod() on TemplateMixedType to return Maybe.

Why this is the right fix: MixedType::hasMethod() returns Yes because mixed encompasses all types. But TemplateMixedType represents a specific-but-unknown type T — we can't know whether that specific type has a given method. Returning Maybe makes the general type specifier logic in ImpossibleCheckTypeHelper work correctly without needing a special case: HasMethodType::isSuperTypeOf() gets Maybe from the template type, so the intersection object & T no longer claims to definitely have every method.

All 11,995 tests pass and make phpstan reports no errors.

[VincentLanglet]

List other possible fixes cause this one is not ok.

MixedType:: and TemplateMixedType methods shouldn't have different result.

[phpstan-bot]

Pushed. The fix now addresses the reviewer's concern:

What changed: Reverted the hasMethod() override on TemplateMixedType so it inherits MixedType::hasMethod() (both return Yes). Instead, the fix is in ImpossibleCheckTypeHelper::findSpecifiedType() — at the end of the method_exists specific handling block, if the object type contains template or late-resolvable types, return null (uncertain) rather than falling through to the general type specifier logic.

Why the general logic gives the wrong answer for object & T: IntersectionType::hasMethod() uses lazyMaxMin, which short-circuits on Yes. Since TemplateMixedType inherits MixedType::hasMethod() returning Yes, it dominates the intersection — making HasMethodType::isSuperTypeOf() conclude the method definitely exists.

Alternatives considered:

1. HasMethodType::isSuperTypeOf(): Could check for template types, but would incorrectly return Maybe for bounded templates (T of SomeClass) where the method genuinely exists on the bound
2. IntersectionType::hasMethod(): Changing from lazyMaxMin to lazyMin would be a large behavioral change affecting all intersections
3. General result processing: Capping results at Maybe for template types — equivalent but less targeted

[VincentLanglet]

I feel like the fix should be inside HasMethodType::isSuperTypeOf() instead.

For instance HasMethodType::isSuperTypeOf(Mixed) should be Maybe only (this would be consistent with MixedType::isSubtypeOf(HasMethod) which is maybe)

[phpstan-bot]

I processed this review but have nothing to report.