Fix phpstan/phpstan#13629: False report for 2.1.30 release "arrayValues.list" ("Parameter X of array_values is already a list, call has no effect")

[phpstan-bot]

Summary

Fixes a false positive where array_values() on a nested array with string keys was reported as "already a list, call has no effect". The issue occurred when an array was built using string keys via nested dim-fetch assignment like $arr[$outerKey][$stringKey] = $value, but PHPStan incorrectly inferred the inner array as a list.

Changes

• Fixed AccessoryArrayListType::setExistingOffsetValueType() in src/Type/Accessory/AccessoryArrayListType.php to return ErrorType when the offset type cannot be an integer. Previously it unconditionally returned $this, preserving the list type even for string key assignments.
• Added rule regression test in tests/PHPStan/Rules/Functions/data/bug-13629.php and tests/PHPStan/Rules/Functions/ArrayValuesRuleTest.php
• Added NSRT test in tests/PHPStan/Analyser/nsrt/bug-13629.php

Root cause

AccessoryArrayListType::setExistingOffsetValueType() always returned $this, meaning it preserved the list accessory type regardless of the offset type being set. When the assign handler processed a nested array assignment like $data[$outerKey][$stringKey] = $value and the scope already tracked $data[$outerKey], it used setExistingOffsetValueType (instead of setOffsetValueType). The setOffsetValueType method correctly returned ErrorType for non-integer/non-null offsets, but setExistingOffsetValueType did not, causing the list type to be incorrectly preserved through the intersection type.

Test

The regression test reproduces the exact scenario from the issue: building a nested array in loops where the inner array uses string keys ($viewHelper['name']), then calling array_values() on it. The test verifies no arrayValues.list error is reported.

Fixes phpstan/phpstan#13629