Apply FunctionParameterClosureTypeExtension override to the in-function-call stack so the closure's inferred return type matches its analysed body

[phpstan-bot]

Summary

preg_replace_callback (and any other function/method whose callback parameter
type is refined by a *ParameterClosureTypeExtension) reported a false positive
Anonymous function should return 'aa' but returns 'possible?' for a callback
whose body clearly returns both values:

preg_replace_callback(
    '/a|(?<b>b)/',
    function (array $match): string {
        if ($match['b'] !== null) {
            return 'aa';
        }
        return 'possible?';
    },
    'abcd',
    flags: PREG_UNMATCHED_AS_NULL,
);

The fix makes the closure's inferred return type use the same (extension-overridden)
parameter types that the closure body is actually analysed with.

Changes

• src/Analyser/MutatingScope.php: add replaceInFunctionCallStackParameterType(),
  which returns a scope whose top inFunctionCallsStack entry carries a replaced
  parameter type.
• src/Analyser/NodeScopeResolver.php: in both the Expr\Closure and
  Expr\ArrowFunction argument branches, after a parameter closure type extension
  produces an overriding type, update the scope passed to
  processClosureNode()/processArrowFunctionNode() with that type. Because this
  lives in the shared argument-processing loop, the same fix applies to function,
  method and static-method parameter closure type extensions.
• Tests:
  • tests/PHPStan/Rules/Functions/data/bug-14914.php + ClosureReturnTypeRuleTest::testBug14914
    — the reported preg_replace_callback reproducer (function extension).
  • tests/PHPStan/Rules/Functions/data/closure-return-type-parameter-closure-extension.php,
    its .neon, and ClosureReturnTypeParameterClosureExtensionRuleTest — custom
    function/method/static-method parameter closure type extensions plus a closure
    and an arrow function, proving the analogous method and static-method cases were
    broken the same way and are now fixed.

Root cause

A closure's return type is inferred by ClosureTypeResolver::getClosureType(),
which re-derives the callable parameter types from the parameter reflection on top
of MutatingScope::$inFunctionCallsStack. That parameter is pushed via
pushInFunctionCall() as the declared callback parameter, before any
FunctionParameterClosureTypeExtension / MethodParameterClosureTypeExtension /
StaticMethodParameterClosureTypeExtension override is computed. The override is
only forwarded to processClosureNode() as $passedToType and used to analyse the
body, so two different parameter types were in play:

• return-type inference used the plain function-map type
  (array<int|string, string>, where $match['b'] is a non-null string, so the
  !== null check is always true and return 'possible?' looks unreachable → the
  return type collapses to 'aa');
• the actual body walk used the overridden regex-shape type ($match['b'] is
  'b'|null, so both branches are live and return 'possible?' is checked against
  the collapsed 'aa').

replaceInFunctionCallStackParameterType() re-aligns the stack with the override so
both paths agree. The pattern affects every parameter closure type extension; the
fix is placed in the shared call-argument loop so function, method and
static-method extensions are all covered, and both closures and arrow functions are
handled.

Test

• ClosureReturnTypeRuleTest::testBug14914 reproduces the exact issue snippet and
  fails without the fix (return.type error on the return 'possible?' line),
  passes with it.
• ClosureReturnTypeParameterClosureExtensionRuleTest registers custom function,
  method and static-method parameter closure type extensions that widen a callback's
  array offset to be nullable; without the fix the function, method and
  static-method closures each raise a false return.type error, and all pass with
  the fix. It also exercises an arrow function on the same code path.

Fixes phpstan/phpstan#14914

[staabm]

this should also fix https://phpstan.org/r/afe20725-1ad2-4a7d-8043-ed517d3499d8

[phpstan-bot]

Done. Here's a summary of how I addressed staabm's review.

What the reviewer asked

this should also fix https://phpstan.org/r/afe20725-1ad2-4a7d-8043-ed517d3499d8

What I found

I retrieved both playground snippets via the PHPStan playground API. Despite the issue text calling it "array-function style", the second link is actually the arrow-function variant of the same preg_replace_callback bug, at level 10, with no explicit return type:

preg_replace_callback(
    '/a|(?<b>b)/',
    fn (array $match) => $match['b'] !== null ? 'aa' : 'possible?',
    'abcd',
    flags: PREG_UNMATCHED_AS_NULL,
);

The existing PR fix (replaceInFunctionCallStackParameterType(), applied in both the closure and arrow-function branches of processArgs) already fixes this case — I confirmed it reports "No errors" with the fix and fails with Anonymous function should return 'aa' but returns 'aa'|'possible?' without it.

The one gap was test coverage: the PR's bug-14914.php reproducer only had the closure form, tested via ClosureReturnTypeRuleTest. Arrow functions go through a different rule (ArrowFunctionReturnTypeRule), which fires on ArrowFunctionReturnStatementsNode — so the reviewer's exact snippet wasn't exercised.

Change made

• Added the arrow-function reproducer (verbatim from the playground) as a second function in tests/PHPStan/Rules/Functions/data/bug-14914.php.
• Added testBug14914() to ArrowFunctionReturnTypeRuleTest asserting no errors.

Verification

• New test fails without the source fix (return 'aa' but returns 'aa'|'possible?' at the arrow-function line) and passes with it — a genuine regression test.
• All 22 tests across the three affected rule test classes pass.
• make phpstan clean.

Committed as de25b6f51 and pushed to the PR branch.