Fix ConstantArrayType::isCallable

[VincentLanglet]

I basically copied the logic findTypeAndMethodNames with the following changes:

• I kept the methods with no as result of $type->hasMethod($method->getValue())
• I ended up with an TrinaryLogic::extremIdentity

Closes phpstan/phpstan#12063

[VincentLanglet]

In findTypeAndMethodNames there is a continue; I don't want to.

[ondrejmirtes]

Why not $has = TrinaryLogic::createNo()?

[VincentLanglet]

cc @herndlm, since you implemented it first in https://github.com/phpstan/phpstan-src/pull/1529/files#diff-2e28cc3b285eae2b224df51cda5d6d532675e945e2995e2cd76293bca56799d6R343

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

Why not $has = TrinaryLogic::createNo()?

[VincentLanglet]

Why not $has = TrinaryLogic::createNo()?

Indeed ; simplified.

[ondrejmirtes]

The implementation if isCallable() needs to be synced with getCallableParametersAcceptors otherwise there are going to be bugs. That's why currently both methods use $this->findTypeAndMethodNames().

[VincentLanglet]

The implementation if isCallable() needs to be synced with getCallableParametersAcceptors otherwise there are going to be bugs. That's why currently both methods use $this->findTypeAndMethodNames().

I provided another solution in 8993085

I can modify findTypeAndMethodNames directly, but that means that I need to allow calling

ConstantArrayTypeAndMethod::createConcrete($type, $method->getValue(), TrinaryLogic::createNo());

which impact the usage in

• UnusedPrivateMethodRule
• getCallableParametersAcceptors

So I dunno if:

• ConstantArrayTypeAndMethod::createConcrete($type, $method->getValue(), TrinaryLogic::createNo()); would make sens
• I need to filter out those value in UnusedPrivateMethodRule and getCallableParametersAcceptors (and add a boolean in findTypeAndMethodNames to filter out automatically)

[ondrejmirtes]

I don't understand why we'd need to create ConstantArrayTypeAndMethod::createConcrete($type, $method->getValue(), TrinaryLogic::createNo()).

I'm sorry, I don't like the current state of this PR enough to merge it. I'd have to look into it myself.

[VincentLanglet]

I don't understand why we'd need to create ConstantArrayTypeAndMethod::createConcrete($type, $method->getValue(), TrinaryLogic::createNo()).

Currently when we call findTypeAndMethodNames on a constantArray:

array{View, 'existingMethod'|'nonExistingMethod'}

the logic done is

• View::existingMethod => exists, we call createConcrete on View, existingMethod, TrinaryLogic::createYes().
• View::nonExistingMethod => doesn't exists, we skip this

Then the array returned is a single ConstantArrayTypeAndMethod so checking all the TrinaryLogic gives a Yes, and we think it's always a callable.

We need a way to track that some values were skipped.

I'm sorry, I don't like the current state of this PR enough to merge it. I'd have to look into it myself.

The other idea I have would be to check that the count of $methods->getConstantStrings() is the same than the count of the result of findTypeAndMethodNames to be sure no value were skipped (because they are TrinaryLogic::createNo()).

• A count of 0 => No
• A different count => Maybe
• A same count => Keep the existing logic

[VincentLanglet]

@ondrejmirtes I repushed the changes with my last idea (based on the count) ; you might prefer it.