Fix phpstan/phpstan#9844: Calling a static method over non-generic class-string results in ErrorType

[phpstan-bot]

Summary

Calling a static method on a non-generic class-string variable (e.g. $class::foo()) incorrectly resulted in *ERROR* type instead of mixed.

Changes

• Modified src/Analyser/ExprHandler/StaticCallHandler.php: When methodCallReturnType returns null and the resolved type is a classless object (from plain class-string), return MixedType instead of ErrorType
• Added regression test tests/PHPStan/Analyser/nsrt/bug-9844.php

Root cause

When resolving static method calls on dynamic class expressions, ClassStringType::getObjectTypeOrClassStringObjectType() returns ObjectWithoutClassType. This type correctly returns TrinaryLogic::createMaybe() for hasMethod(), but MutatingScope::filterTypeWithMethod() requires yes(), causing it to return null. The StaticCallHandler then defaulted to ErrorType.

The fix detects the case where the resolved type is a classless object type (isObject()->yes() with no class names) — which corresponds to a plain class-string — and returns MixedType instead of ErrorType, since any class could have any method returning any type.

Test

Added tests/PHPStan/Analyser/nsrt/bug-9844.php which verifies that $class::foo() where $class: class-string produces mixed type.

Fixes phpstan/phpstan#9844

[staabm]

fix failling tests

[VincentLanglet]

I would not blindy this fix this looking at https://phpstan.org/r/02f65472-153c-496a-ace9-8d3747108f7d

It's ErrorType for both static and non static call, which is consistent
There is currently an error reported for the non static call

So I wonder if it's not better to report an error (in the StaticMethodCallCheck) for the static call.

[staabm]

I think we cannot say its a undefined method.. we should say its a maybe undefined method (so the error will depend on rule-level)?

but type-inference wise, I think its not correct to turn this into a ERROR in case we are not sure

[phpstan-bot]

API Error: 529 {"type":"error","error":{"type":"overloaded_error","message":"Overloaded. https://docs.claude.com/en/api/errors"},"request_id":"req_011CZTGsTLp3w35p9Y6ix7va"}

[VincentLanglet]

I think we cannot say its a undefined method.. we should say its a maybe undefined method (so the error will depend on rule-level)?

but type-inference wise, I think its not corret to turn this into a ERROR in case we are not sure

If you look at https://phpstan.org/r/e4c2ded1-e04e-4d7f-b439-cec1111fabf1

• $object::method is ErrorType and reported
• $object->method is ErrorType and reported
• $classString::method is ErrorType and not reported

If we consider this as MixedType, it should be mixedType for the 3 situation IMHO.
And If we consider this as "maybe undefined", it should be the same for the other situation.

I would just say for consistency it should stay ErrorType and be reported.
Especially because it's easy to fix the error by changing the phpdoc to class-string<Foo>

[staabm]

I would just say for consistency it should stay ErrorType and be reported.

the error message Call to an undefined method object::foo(). does not depend on the ErrorType.
with this PR we get still the error but a MixedType.

this PR does not change which errors we report for your given example

Especially because it's easy to fix the error by changing the phpdoc to class-string

I think class-string is a valid type and in some circumstances cannot be narrowed with a generic (or might appear while analysis without a known generic type)

[VincentLanglet]

the error message Call to an undefined method object::foo(). does not depend on the ErrorType. with this PR we get still the error but a MixedType.

ErrorType extends MixedType ; so I'm not sure of the gain to change this type into MixedType.
Maybe ErrorType is especially here to avoid reporting tons on extra error on the following lines...

this PR does not change which errors we report for your given example

Yes, but maybe we should. And start reporting $classString::method as a potential error.

I think class-string is a valid type and in some circumstances cannot be narrowed with a generic (or might appear while analysis without a known generic type)

Which one ?
If you can $unknownClassString::method you cannot be sure method exists.
On the other site, if the class string is types class-string<Foo> you'll be sure.

[staabm]

Yes, but maybe we should. And start reporting $classString::method as a potential error.

sounds like a independent topic to me

Which one ?
If you can $unknownClassString::method you cannot be sure method exists.
On the other site, if the class string is types class-string<Foo> you'll be sure.

e.g. if you have logic which is typed on object only:

function doFoo(object $o) {
  $class = get_class($o);
}

in such general purpose functions we won't/cannot get something narrower than class-string:

https://phpstan.org/r/a6589c01-37ac-4af7-b5ce-32fdf5d5314c

[staabm]

fix failling tests

[phpstan-bot]

make tests also completed successfully (exit code 0). Everything is green — tests and static analysis all pass. The fix has already been pushed.

[staabm]

apply similar fixes to fix failling tests (without changing test expectations)

[phpstan-bot]

Done. Applied the same fix from StaticCallHandler to MethodCallHandler: when methodCallReturnType returns null and the resolved type is a classless object (from plain class-string), return MixedType instead of ErrorType. This fixes the two failing assertions on lines 16-17 of bug-9844.php ($class->foo() and $class?->foo()).

All tests pass (11674 tests, 0 failures) and make phpstan reports no errors.

[staabm]

ah nice, I think the new error in phpstan-latte is valid