ArrayType::isCallable(): ask StringType::isSuperTypeOf() about the item type instead of only isString()

[phpstan-bot]

Summary

callable&array<mixed>, callable&list<mixed> and callable-array were recognized but not enforced. As reported in the issue, PHPStan reported nothing at all for these — not a wrong method name, not [1, 2], not even 42 — while the shaped form callable&array{class-string|object, string} rejected all of them.

The reason is that the intersection collapsed to never before any rule saw it, and never is accepted by everything. This PR makes ArrayType::isCallable() answer correctly for item types that are supertypes of string, which keeps the intersection alive and restores the acceptance check in every position.

Changes

• src/Type/ArrayType.php — isCallable() no longer derives its answer solely from $this->itemType->isString(). When that says No, it now also asks (new StringType())->isSuperTypeOf($this->itemType)->maybe() before concluding the array cannot be callable.

Positions that were silent before and now report (all share the RuleLevelHelper code path, so all are fixed by the one change; each was verified to be broken before the fix):

• function arguments — tests/PHPStan/Rules/Functions/data/bug-13114.php
• return statements — tests/PHPStan/Rules/Functions/data/bug-13114-return.php
• property assignments — tests/PHPStan/Rules/Properties/data/bug-13114.php
• method / static method / constructor / __invoke / callable-value arguments and parameter default values (manually verified, covered transitively by the same check)
• values narrowed by is_callable() at level 10, where the narrowed array<mixed>&callable was previously unusable as an argument type

Analogous constructs probed and found already correct, so no test was kept for them:

• callable&string / callable-string and callable&object / callable-object — these do not nest a mixed and never collapsed
• callable&iterable, Traversable<mixed, mixed>&callable, array{mixed, mixed}&callable (ConstantArrayType::isCallable() returns Maybe via its "unknown method name" path)
• every other zero-argument TrinaryLogic-returning Type method, compared for array<mixed>, list<mixed>, non-empty-array<mixed>, iterable<mixed>, array{mixed, mixed} and ArrayObject<mixed, mixed> against their strict-mixed rewrites — isCallable() was the only divergence
• MissingTypehintCheck::getIterableTypesWithMissingValueTypehint() deliberately skips the array member of a callable array, which explains the missingType.iterableValue observation in the issue; that is intended and left alone

Root cause

StrictMixedType answers No to every isX() query (isString(), isObject(), isArray(), …) even though its isSuperTypeOf() / accepts() return Yes for every type. That is deliberate — it is how levels 9/10 force explicit narrowing — but it makes any nested StrictMixedType lie to container types that ask isX() about their item type.

ArrayType::isCallable() was such a container query:

return TrinaryLogic::createMaybe()->and($this->itemType->isString());

At levels 9 and 10, RuleLevelHelper::transformCommonType() (and transformAcceptedType()) rewrite nested mixed into StrictMixedType via TypeTraverser::map(). IntersectionType::traverse() rebuilds the intersection with TypeCombinator::intersect(), which asks CallableType::isSuperTypeOf(array<strict-mixed>); that delegates to ArrayType::isCallable(), got No, and intersect() returned NeverType.

The parameter/return/property type the rules then received was never, and never->accepts(anything) is Yes, so RuleLevelHelper::accepts() never produced an error. This is why the whole check disappeared rather than merely weakening — and why level 9 broke callable&array<mixed> (explicit mixed) while level 10 additionally broke callable-array (implicit mixed), with levels 0–8 behaving correctly.

Asking isSuperTypeOf() instead is the standard way to phrase "could this type overlap with string" and gives the right answer for StrictMixedType (Maybe) while preserving the previous No for array<int>, array<object>, array<never> and array<mixed~string>.

Test

• CallToFunctionParametersRuleTest::testBug13114() runs the issue's playground sample plus zonuexe's probes ([new C, 'missing'], [1, 2], 42) over three RuleLevelHelper configurations — (explicitMixed, implicitMixed) = (false, false), (true, false), (true, true) — and asserts the same errors in all three. Data sets Nicer Markdown #1 and SoapClient - fixed signature map for SoapClient::__call #2 fail without the fix; #0 passes and locks in the levels-0–8 behaviour that already worked. The same data file covers callable&string / callable&object and the two is_callable()-narrowing cases.
• ReturnTypeRuleTest::testBug13114() — @return callable&array<mixed> with a bad return [new C, 'h'];. Silent before the fix.
• TypesAssignedToPropertiesRuleTest::testBug13114() — @var callable-array and @var callable&array<mixed> properties assigned [new C, 'h'] and 42. Silent before the fix.
• TypeCombinatorTest::dataIntersect() — two cases pinning the type-level behaviour directly: intersect(array<strict-mixed>, callable) is non-empty-list<mixed>&callable(): mixed (was *NEVER*), and intersect(array<int>, callable) stays *NEVER*.

Fixes phpstan/phpstan#13114