Do not treat method_exists() as always true for @method-annotated methods

[phpstan-bot]

Summary

When an interface or class has a @method PHPDoc annotation, PHPStan incorrectly reports method_exists() checks as always evaluating to true. Since @method-annotated methods are virtual (typically handled by __call()) and don't exist as actual PHP methods, method_exists() may return false at runtime.

Changes

• Modified src/Rules/Comparison/ImpossibleCheckTypeHelper.php:
  • For object types: when hasMethod() returns yes, additionally verify via ClassReflection::hasNativeMethod() that the method is actually declared in PHP code, not just via @method annotation. Return null (indeterminate) instead of true when only a @method annotation exists.
  • For generic class-string types: applied the same hasNativeMethod() guard before reporting always-true.
• Added test data at tests/PHPStan/Rules/Comparison/data/bug-6211.php covering:
  • @method on an interface, checked via object instance and class string
  • @method on a class directly
  • Native methods still correctly reported as always-true
  • @property with __get() correctly handled (already working via PropertyExistsTypeSpecifyingExtension)

Root cause

ImpossibleCheckTypeHelper::findSpecifiedType() used $objectType->hasMethod() to determine if method_exists() would always return true. hasMethod() delegates to ClassReflection::hasMethod(), which includes methods from AnnotationsMethodsClassReflectionExtension (i.e., @method PHPDoc annotations). Since these annotations describe methods that may be handled by __call() but don't create real PHP methods, method_exists() should not be considered always-true for them.

The fix uses ClassReflection::hasNativeMethod() to verify the method is an actual PHP method before reporting the check as always-true.

Analogous cases probed

• property_exists() with @property: Already correctly handled — PropertyExistsTypeSpecifyingExtension checks $propertyReflection->isNative() at line 87 and returns empty specifiers for non-native properties.
• method_exists() with class-string: Fixed in the same PR — the generic class-string code path in ImpossibleCheckTypeHelper had the same issue.

Test

Regression test testBug6211 in ImpossibleCheckTypeFunctionCallRuleTest with test data covering @method on interfaces and classes, both via object instances and class strings, alongside native methods that should still be reported as always-true.

Fixes phpstan/phpstan#6211

[VincentLanglet]

The rule should still report a method_exists already specified to true.

// @method should not make method_exists always true
if (\method_exists($hell, 'isTrue')) {
    if (\method_exists($hell, 'isTrue')) { // This one should be reported

     }
}

Also if we finally check native type ; is it still needed to check hasMethod($methodType->getValue())->yes() before ?

[phpstan-bot]

Done. Here's a summary of the changes made to address the review:

Review point 1: Nested method_exists() should still be reported when already specified to true

Two coordinated changes:

1. MethodExistsTypeSpecifyingExtension: Now also specifies the method_exists() FuncCall expression as ConstantBooleanType(true) in the scope (via unionWith), in addition to narrowing the argument type. This makes the scope track that method_exists(...) was already established as true inside an if (method_exists(...)) block.

2. ImpossibleCheckTypeHelper: Added an early $scope->hasExpressionType($node)->yes() check at the top of the constant-method-name block. This detects nested method_exists() calls that were already established by a prior check and returns true (always-true), regardless of whether the method is native or from @method. This handles both object instances and class-string arguments uniformly.

Review point 2: "Is hasMethod() check still needed before hasNativeMethod()?"

Yes, it's still needed. The hasMethod()->yes() guard distinguishes three cases: (a) native method → return true, (b) @method only → return null, (c) method doesn't exist → fall through to hasMethod()->no() which returns false. Without it, @method methods would fall through to general logic which incorrectly reports them as always-true.

[VincentLanglet]

Does the issue exists for property_exists ; if not, why ? Can't the method_exist behave the same way ?

[VincentLanglet]

property_exists is not statisfying cause it reports

if (property_exists($task, $a)) {
			if (property_exists($task, $a)) {
			
			}
		}

but not

if (property_exists($task, '$a')) {
			if (property_exists($task, '$a')) {
			
			}
		}

[VincentLanglet]

property_exists is not statisfying cause it reports

if (property_exists($task, $a)) {
			if (property_exists($task, $a)) {
			
			}
		}

but not

if (property_exists($task, '$a')) {
			if (property_exists($task, '$a')) {
			
			}
		}

[phpstan-bot]

Pushed. Here's a summary of the changes:

What the reviewer asked for: Nested method_exists()/property_exists() calls inside a truthy branch should be reported as always-true, even when the method/property only exists via @method/@property PHPDoc annotation. The reviewer pointed out that just returning empty SpecifiedTypes (copying the property_exists pattern) is insufficient because it prevents nested check detection.

Three coordinated changes:

1. MethodExistsTypeSpecifyingExtension: When a method exists only via @method annotation, instead of returning empty SpecifiedTypes([], []), returns a FuncCall-as-true spec that stores method_exists(...) as ConstantBooleanType(true) in scope. This doesn't narrow the object type (correct — the method might not exist at runtime) but does mark the expression so nested checks can detect it.

2. PropertyExistsTypeSpecifyingExtension: Same change for @property annotations — returns a FuncCall-as-true spec instead of empty SpecifiedTypes.

3. ImpossibleCheckTypeHelper::findSpecifiedType(): Added an early check at the top: if the FuncCall node already has a stored constant boolean type in scope (from an outer check), return it directly. This bypasses the method_exists special-case logic that would otherwise return null for @method-only methods. Uses isTrue()/isFalse() instead of instanceof ConstantBooleanType per codebase conventions.

[VincentLanglet]

This is the same code than line 61, this can be refactored ; maybe a private method ?

[phpstan-bot]

Pushed. Here's a summary of the changes:

Two refactoring changes requested by the reviewer:

1. MethodExistsTypeSpecifyingExtension: Extracted duplicated FuncCall-as-true spec creation into a createFuncCallSpec() private method. This removes the eager $funcCallSpec variable and defers creation until actually needed. All three call sites (non-constant method name, constant class-string with @method, object type with @method) now use the private method. Also fixed a remaining $funcCallSpec reference in the getClassStringObjectType() path that was added by a concurrent remote change.

2. PropertyExistsTypeSpecifyingExtension: Same extraction — duplicated code at lines 61 and 88 now calls createFuncCallSpec().

Regarding the previous review question about ImpossibleCheckTypeHelper line 257: The hasNativeMethod() check in the generic class-string path is still needed. I verified by removing it — the test for method_exists($classString, 'test') where $classString: class-string<Foo> fails because the general type specifier path can't determine always-true for class-string types (since HasMethodType::isSuperTypeOf(class-string<Foo>) returns maybe, not yes). The fast path is the only way to correctly report native methods as always-true for generic class-strings.

[VincentLanglet]

This should be reported ; fix it.

[phpstan-bot]

Pushed. The fix adds an early scope check in the method_exists fast path of ImpossibleCheckTypeHelper: before the hasNativeMethod guard, it checks whether the scope already has the method_exists() FuncCall stored as a constant boolean (from an outer if (method_exists(...)) block). This correctly reports the inner nested call as always-true, even for @method-only methods. The check uses isTrue()/isFalse() to examine the actual stored type value, addressing the previous review concern about blindly returning true.