Fix phpstan/phpstan#14297: Regression: type narrowing on non-empty-list array shape

[phpstan-bot]

Summary

When a constant array type with optional keys (e.g., non-empty-list{0?: 'a'|'b', 1?: 'b'}) was narrowed using a count() check like count($a) === 2, the true branch correctly narrowed to the specific shape, but the else branch kept the original unnarrowed type instead of narrowing to the complementary shape.

Changes

• Added falsey context handling in specifyTypesForCountFuncCall() in src/Analyser/TypeSpecifier.php — for constant array types, computes the remaining possible size by removing the checked size from the array's size range, then recursively calls with the negated (truthy) context to build the narrowed type
• Updated test expectations in tests/PHPStan/Analyser/nsrt/list-count.php for the improved else-branch narrowing behavior
• Added array_values() in src/Reflection/InitializerExprTypeResolver.php and src/Type/Php/ArrayChangeKeyCaseFunctionReturnTypeExtension.php to preserve list types for constructor parameters affected by the more precise narrowing

Root cause

The specifyTypesForCountFuncCall() method had a continue that skipped array types in the falsey context when isSizeSuperTypeOfArraySize was maybe. This meant constant arrays with optional keys — where the size is a range rather than exact — got no narrowing in the else branch. The fix computes what count values remain possible after excluding the checked value, and then reuses the existing truthy narrowing logic to build the correct narrowed type.

Test

Added tests/PHPStan/Analyser/nsrt/bug-14297.php which reproduces the original issue: after filtering and counting a list with optional keys, verifying that count($a) === 2 in the else branch correctly narrows to the single-element shape.

Fixes phpstan/phpstan#14297

[ondrejmirtes]

In src/Reflection/InitializerExprTypeResolver.php and src/Type/Php/ArrayChangeKeyCaseFunctionReturnTypeExtension.php you added array_values calls.

I suspect it's because make phpstan started showing errors.

But in these cases it's obvious the array is already a list. Fix the analyser so that these calls are not needed. And remove them so that the diff doesn't touch any unrelated code to the actual type inference and narrowing.

[phpstan-bot]

Done. Here's what I did:

Root cause: When specifyTypesForCountFuncCall builds narrowed constant arrays with optional keys using ConstantArrayTypeBuilder, the builder's nextAutoIndexes tracking degrades isList from yes to maybe. This happens because after an optional key at position N, the next key at N+1 falls between min(nextAutoIndexes) and max(nextAutoIndexes), which the builder interprets as potentially creating a gap.

Fix (in src/Analyser/TypeSpecifier.php): After the builder produces the array, if we know the original type was a list ($isList->yes()) but the builder degraded it (!$builder->isList()), call makeList() on the resulting ConstantArrayType to restore the list flag.

Removed workarounds: Reverted the array_values() calls in InitializerExprTypeResolver.php and ArrayChangeKeyCaseFunctionReturnTypeExtension.php since they're no longer needed — the analyser now correctly recognizes those arrays as lists.

[phpstan-bot]

I processed this review but have nothing to report.

[mvorisek]

Please see phpstan/phpstan#11488 (comment), this change does not seem to be right.

[ondrejmirtes]

@mvorisek Please open a new bug report and show what this has broken. You have a few hours until release 😊