Add multi-variant overloads for PDOStatement::fetchAll() in function signature map

[phpstan-bot]

Summary

PDOStatement::fetchAll() had a single function map entry with fetch_argument typed as int|string|callable, which caused false positives when passing constructor arguments (an array) as the third parameter in FETCH_CLASS mode. The fix adds proper multi-variant overloads.

Changes

• resources/functionMap.php: Replaced single PDOStatement::fetchAll entry with 4 variants:
  • Base: (int $how) — for simple fetch modes like FETCH_ASSOC
  • Variant 1: (int $fetch_column, int $colno) — for FETCH_COLUMN
  • Variant 2: (int $fetch_class, string $classname, ?array $ctorargs) — for FETCH_CLASS
  • Variant 3: (int $fetch_func, callable $callback) — for FETCH_FUNC
• resources/functionMap_php80delta.php: Same overloads with array return type (instead of array|false)
• Added regression test in tests/PHPStan/Rules/Methods/data/bug-5509.php

Root cause

The function map had a single signature where the second parameter was typed as int|string|callable — a union of all possible types across different fetch modes. When calling fetchAll(PDO::FETCH_CLASS, StdClass::class, [new StdClass]), the array constructor argument didn't match any type in the variadic expansion of int|string|callable. The fix follows the established pattern already used by PDO::query and PDOStatement::setFetchMode, which have separate overload variants for each fetch mode.

Analogous cases checked

• PDO::query — already has proper overloads (variants '1, '2, '3)
• PDOStatement::setFetchMode — already has proper overloads (variants '1, '2, '3)
• PDOStatement::fetch — has fixed parameter types (int, int, int), no mode-dependent types needed

Test

• tests/PHPStan/Rules/Methods/data/bug-5509.php: Tests all valid calling patterns of fetchAll() — FETCH_CLASS with class name and constructor args, FETCH_CLASS with just class name, FETCH_COLUMN with column number, FETCH_FUNC with callable, no args, and just mode.

Fixes phpstan/phpstan#5509

[VincentLanglet]

Add PHP8+ test with

$pdo = new PDO(
	dsn: "mysql:host=servername;dbname=dbname;charset=utf8mb4",
	username: "username",
	password: "password"
);

$dbQuery = $pdo->prepare("SELECT * FROM table;");

$dbQuery->fetchAll(mode: PDO::FETCH_DEFAULT);

$dbQuery->fetchAll(
	mode: PDO::FETCH_COLUMN,
	column: 1
);

$dbQuery->fetchAll(
	mode: PDO::FETCH_CLASS,
	class: "class"
);

Name arguments should work correctly

[phpstan-bot]

Done. I've added named argument tests for PDOStatement::fetchAll() using mode: which is the only valid named argument for this method.

Regarding the reviewer's suggestion to also test column: and class: as named arguments — those cannot work because PDOStatement::fetchAll is an internal PHP function whose signature is fetchAll(int $mode = PDO::FETCH_DEFAULT, mixed ...$args). PHP does not accept arbitrary named parameters for variadic params on internal functions (it throws "does not accept unknown named parameters" at runtime). PHPStan correctly reports "Unknown parameter" for these cases.

[VincentLanglet]

fetchAll() uses overloaded signatures — the available named parameters change depending on which $mode you pass.

So the four signature

PDOStatement::fetchAll(int $mode = PDO::FETCH_DEFAULT): array
PDOStatement::fetchAll(int $mode = PDO::FETCH_COLUMN, int $column): array
PDOStatement::fetchAll(int $mode = PDO::FETCH_CLASS, string $class, ?array $constructorArgs): array
PDOStatement::fetchAll(int $mode = PDO::FETCH_FUNC, callable $callback): array
```
should be usable with the named parameters (for all parameters).

[phpstan-bot]

Here's a summary of what was done to address the review:

Problem: The reviewer requested that PDOStatement::fetchAll() support named arguments for all parameters (not just mode:), matching PHP 8.4's actual runtime behavior where column:, class:, and constructorArgs: are accepted as named arguments.

Changes made:

1. Function map parameter names (functionMap.php, functionMap_php80delta.php): Renamed parameters to match PHP's actual named argument names: mode, column, class, constructorArgs, callback (previously how, fetch_column/colno, fetch_class/classname/ctorargs, fetch_func).

2. Php8SignatureMapProvider: Two changes:

   • Modified the hasMiddleVariadicParam check to only consider function map variadic params (not native), preventing incorrect skipping of variants with more params than native.
   • When a native variadic param is encountered, conditionally include remaining function map params in the named variant (using their function map names), but only when all preceding param names match native. This prevents false positives for methods like PDO::query that don't support variadic-slot named params.

3. ParametersAcceptorSelector: Enhanced type matching to look up argument types by parameter name when numeric indices don't match (for named argument calls), and to reject variants whose required params don't have matching named arguments.

4. Test: Added named argument test cases for column:, class:, and constructorArgs:.

[VincentLanglet]

Should we also/instead improve ParametersAcceptorSelector::selectFromArgs in order to support this method ? Like it's the case for
ArrayMapArgVisitor
CurlSetOptArgVisitor
ArrayFilterArgVisitor
ImplodeArgVisitor
and more ?

[phpstan-bot]

Both pass cleanly. There are no code changes needed for this review comment — it's a design question that should be answered in the PR discussion.

The reviewer's question "Should we also/instead improve ParametersAcceptorSelector::selectFromArgs?" has a clear answer: No, the multi-variant overload approach is the correct pattern here. Here's why:

1. Consistency: PDO::query and PDOStatement::setFetchMode both use the same multi-variant overload approach without any argument visitor. This PR follows the established pattern.

2. Different use case: The selectFromArgs visitors (like CurlSetOptArgVisitor) solve a different problem — they refine a mixed parameter type based on the value of another parameter in a single function signature. For fetchAll(), the variants already have distinct parameter types (int vs string vs callable for the 2nd param), so selectFromTypes can already pick the correct variant without inspecting constant values.

3. Marginal benefit: A visitor that inspects the actual PDO::FETCH_* constant value would only add value if we wanted to reject calls where e.g. PDO::FETCH_ASSOC is passed with a column number. But that's a stricter check than needed, and would cause false positives when the mode isn't statically known (e.g., comes from a variable or function call).

Since there are no code changes to make and nothing to push, the response to this review is explanatory. The tests and static analysis all pass.

[VincentLanglet]

FILE: src/Reflection/SignatureMap/Php8SignatureMapProvider.php

FOUND 1 ERROR AFFECTING 1 LINE

298 | ERROR | [x] Function array_slice() should not be referenced via a
| | fallback global name, but via a use statement.
| | (SlevomatCodingStandard.Namespaces.ReferenceUsedNamesOnly.ReferenceViaFallbackGlobalName)

PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY

[phpstan-bot]

Fixed the coding standard violation by adding use function array_slice; to the import list in Php8SignatureMapProvider.php. Both make phpstan and the tests pass. Committed and pushed.

[staabm]

in the docs on https://www.php.net/manual/en/class.pdostatement.php

I can see

can we make more tests out of that?

[phpstan-bot]

Added tests for PDOStatement implementing IteratorAggregate and Traversable as the reviewer requested:

• foreach iteration over PDOStatement
• Calling getIterator() on PDOStatement
• Passing PDOStatement to Traversable and IteratorAggregate typehints

All tests pass (12044 tests, 79632 assertions) and make phpstan reports no errors.