Did not update the test data, but cover the fact these instance methods called statically do not exist.

The problem here is that this actually works: https://3v4l.org/mTa9S

It only doesn't work from the outside: https://3v4l.org/dUmHk

The same problem is covered in CallStaticMethodRule here:

So we should replicate the same logic here. We can take advantage of Scope being passed to getCallableParametersAcceptors and also pass it along to findTypeAndMethodName but as an optional parameter because of backward compatibility (but go through all the current call sites and pass Scope in it).

One problem I'm hitting: isCallable does not have a scope, and that's where findTypeAndMethodName seems to be invoked from. So I added OutOfClassScope, to check if we're in a class. If not, return null, but that always returns false.

EDIT: The fix appears to update $has to maybe if we are not in a class context.

Having ConstantArrayType return maybe on a static call outside of the class or in class with mismatching class names seems to have resolved this. Thanks for the tip!

The problem here is that this actually works: https://3v4l.org/mTa9S

It only doesn't work from the outside: https://3v4l.org/dUmHk

The same problem is covered in CallStaticMethodRule here:

So we should replicate the same logic here. We can take advantage of Scope being passed to getCallableParametersAcceptors and also pass it along to findTypeAndMethodName but as an optional parameter because of backward compatibility (but go through all the current call sites and pass Scope in it).

Passing out of class scope here is causing grief for CallStaticMethodsRuleTest::testBug1971

After circling around this issue for the past few weeks, I think we need to pass the scope to isCallable. Knowing if something is callable depends on the scope so we can check the current class. A non-static method on a class can be invoked statically if it is within the same class. This is will always be false given OutOfClassScope.

This would also improve detection in ConstantStringType. I didn't want to make the big change without first discussing.

The OutOfClassScope scope here is what is causing the test failures for CallStaticMethodsRuleTest::testBug1971.

1) PHPStan\Rules\Methods\CallStaticMethodsRuleTest::testBug1971
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'16: Parameter #1 $callback of static method Closure::fromCallable() expects callable(): mixed, array{class-string<static(Bug1971\HelloWorld)>, 'sayHello2'} given.
+'14: Parameter #1 $callback of static method Closure::fromCallable() expects callable(): mixed, array{'Bug1971\\HelloWorld', 'sayHello'} given.
+15: Parameter #1 $callback of static method Closure::fromCallable() expects callable(): mixed, array{class-string<static(Bug1971\HelloWorld)>, 'sayHello'} given.
+16: Parameter #1 $callback of static method Closure::fromCallable() expects callable(): mixed, array{class-string<static(Bug1971\HelloWorld)>, 'sayHello2'} given.
 '

What about a new class called InAnyClassScope that returns true from all the can* methods?

We'd still get the actual validation because getCallableParametersAcceptors accepts the real scope.

I wasn't sure if this should be pushed to the top of the method – to provide a value for a default nullable meant for backward compatibility. Or instantiated when it's finally needed.

I believe adding the scope to ConstantStringType::isCallable will also cause this test failure to be fixed. Without the scope to know if we're in a class or not, this always returns as yes for the method being callable when it actually may not be.

			$classRef = $reflectionProvider->getClass($matches[1]);
			if ($classRef->hasMethod($matches[2])) {
				return TrinaryLogic::createYes();
			}

What about a new class called InAnyClassScope that returns true from all the can* methods?

We'd still get the actual validation because getCallableParametersAcceptors accepts the real scope.