Update ConstantArrayType::accepts() for lists

[VincentLanglet]

First fix of phpstan/phpstan#11600
but does not close the issue since the second part is not fixed (and is a hard one...).

[VincentLanglet]

Since it's decided by the early return about list we don't have the information anymore.

• Not sure if it's an ok loss or we need to keep this (and how)
• Not sure if we need an help "This must be a list"

Your call.

[VincentLanglet]

This fix is needed or

phpstan-src/tests/PHPStan/Rules/Properties/data/bug-3339.php

Line 4 in 2e27573

will fail.

PHPStan was considering that

$this->tuple = [true, true, true];

		for ($i = 0; $i < 3; ++$i)
		{
			$this->tuple[$i] = false;
		}

// Here, `$this->tuple` is array{bool, bool, bool} but is not considered as a list

I added a non regression test array-is-list-offset.php which fails without this fix.

The idea is to not touch the list property if we're in the case

if ($match) {
					$this->valueTypes = $valueTypes;
					return;
				}

were all the constantScalar keys are already matching.

[VincentLanglet]

This assertion is false

phpstan-src/tests/PHPStan/Analyser/nsrt/array-is-list-unset.php

Line 22 in 2e27573

assertType('false', array_is_list($a));

cf https://onlinephp.io/c/28b76

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

Please separate the changes outside of ConstantArrayType::accepts() to another PR and add proper tests there.

I'd expect new test methods added to ConstantArrayTypeBuilderTest.

[VincentLanglet]

With all the existing fix merged, this PR is now minimal.

This commit does the fix with a test 13b6747

But as shown by https://github.com/phpstan/phpstan-src/actions/runs/10943488747/job/30383079314?pr=3381 we're getting an error

Parameter #2 $expectedErrors of method                                                                 
         PHPStan\Testing\RuleTestCase<PHPStan\Rules\Comparison\ImpossibleCheckTypeFunctionCallRule>::analyse()  
         expects list<array{0: string, 1: int, 2?: string|null}>,                                               
         list<array{0: string, 1: int, 2?: string}> given.         

because of the code

static function (array $i): array {
    if (($i[2] ?? null) === 'BUG') {
         unset($i[2]);
     }

     return $i;
},

This is because of the unset call which means the array may not be a list in the PHPStan definition.

It's easily fixed with an array_values call but

• The error message is not helping
• Technically the PHPdoc ask for array{0: string, 1: int, 2?: string|null} but never asked for a "PHPStan-list" in the way that the next offset might be something else than 3.

I didn't see an easy way to solve this situation unless PHPStan stop to consider that

list{string, string}

and

array{0: string, 1: string}

are the same thing when it comes from the phpdoc. list need to be explicit.

That would require to change

phpstan-src/src/PhpDoc/TypeNodeResolver.php

Line 973 in e8027e7

$builder = ConstantArrayTypeBuilder::createEmpty();

to something like

$builder = ConstantArrayTypeBuilder::createEmpty();
if ($typeNode->kind !== ArrayShapeNode::KIND_LIST) {
     $builder->degradeListCertainty();
}

which would do $this->list = $this->list->and(TrinaryLogic::createMaybe()).

I can try create another PR with such change but I'd like your opinion on this @ondrejmirtes.
It's an "important" change in the way PHPStan understand array vs list...

[ondrejmirtes]

What about $type->isList()->maybe()? I think that at that point the $result below should be assigned to createMaybe() and not createYes()

[VincentLanglet]

I added 102b53b

but what about the following issue #3381 (comment) ?

[ondrejmirtes]

I don't really know what to do about that. Maybe this whole change is a hack and we need to approach it differently.

[VincentLanglet]

I think your right and this things is a hack, or at least not the right fix because it's not really related to list.

PHPStan sometimes consider an array is ordered and sometimes not.

An easy reproducer is https://phpstan.org/r/1ffe9cb5-65b1-4a7c-9010-3aa24560b462 vs real world example https://3v4l.org/TqTBn

Maybe ConstantArray::getKeysOrValuesArray is wrong... or a ordered-array (or unordered-array) need to be introduced...

At least this PR helped to find some others bugs.