Fix phpstan/phpstan#7280: array_reduce could infer the precise type of the $initial argument within the callable and in the return type

[phpstan-bot]

Summary

array_reduce now infers the precise type of the $initial argument as the $carry parameter type within the callback. Previously, $carry was typed as mixed (from the function signature), which when intersected with the closure's native type hint gave only broad types like array or non-empty-array. Now, constant array shapes like array{starts: array{}, ends: array{}} are preserved inside the callback.

Changes

• Added src/Type/Php/ArrayReduceCallbackClosureTypeExtension.php — a new FunctionParameterClosureTypeExtension that overrides the callback parameter types for array_reduce:
  • The carry parameter gets the generalized initial argument type (preserves array shapes, generalizes scalar literals like 0 → int)
  • The value parameter gets the array's iterable value type
• Added tests/PHPStan/Analyser/nsrt/bug-7280.php — regression test covering:
  • Constant array shape initial values (the primary use case from the issue)
  • Scalar initial values (int, string)
  • No initial value (defaults to null)
  • Arrow functions

Root cause

The function signature for array_reduce in functionMap.php declares the callback as callable(mixed,mixed):mixed. This meant the carry parameter had no type information beyond mixed, so PHPStan could only use the closure's native type hints. By implementing a FunctionParameterClosureTypeExtension, the initial argument's type is now propagated to the carry parameter, which is then intersected with the native type hint to produce precise types inside the callback body.

Test

The regression test verifies that:

• $carry inside a callback with initial: ['starts' => [], 'ends' => []] is typed as array{starts: array{}, ends: array{}} (was non-empty-array)
• Scalar initial values like 0 and '' are generalized to int and string (no over-narrowing)
• Missing initial value correctly types carry as null

Fixes phpstan/phpstan#7280

[staabm]

I think this type is wrong. it only is correct for the first invocation when initial is used.

in this example, I think we need to aim for `assertType("array{starts: array, ends: array}", $carry);

[staabm]

Suggested change

	assertType('null', $carry);
	assertType('int|null', $carry);

[VincentLanglet]

This is wrong

assertType("array{starts: array{}, ends: array{}}", $carry);

and

assertType('null', $carry);

are only true for the first iteration but not for the following one.

The inferred type should be closer to

assertType("array{starts: array, ends: array}", $carry);

and

assertType('int|null', $carry);

[phpstan-bot]

Done. Here's what I changed:

Problem: The $carry parameter type in array_reduce callbacks only accounted for the initial value type, which was wrong for iterations after the first one (where $carry receives the callback's return value).

Fix in ArrayReduceCallbackClosureTypeExtension.php: When the callback is a closure/arrow function with a declared return type, union that return type with the generalized initial type. This correctly represents that $carry can be either the initial value (first iteration) or the callback's return value (subsequent iterations).

Test changes:

• Test 1: array{starts: array{}, ends: array{}} → array (union of initial shape with array return type)
• Test 3: null → int|null (union of null initial with int return type)