Fix phpstan/phpstan#10862: Invalid array key for constant array append when negative keys are used since PHP 8.3 by phpstan-bot · Pull Request #5412 · phpstan/phpstan-src

phpstan-bot · 2026-04-06T17:40:16Z

Summary

PHP 8.3 completed the negative array index RFC (originally from PHP 8.0) by fixing $a[] = value to use max_existing_key + 1 even when all keys are negative. PHPStan always computed the next auto-index as max(0, max_key + 1), producing incorrect types like array{-4: 1, 0: 2} instead of array{-4: 1, -3: 2} on PHP 8.3+.

Changes

src/Type/Constant/ConstantArrayTypeBuilder.php: Extended the auto-index update condition to also trigger for negative keys on PHP 8.3+ when no positive key has been set yet (i.e., when $max === 0, the initial default)
Added PhpVersionStaticAccessor import to access PHP version info

Root cause

In ConstantArrayTypeBuilder::setOffsetValueType(), the condition $offsetValue >= $max controlled whether a key updates the next auto-index. Since nextAutoIndexes starts at [0], negative keys (e.g., -4) never satisfied $offsetValue >= 0, so the auto-index stayed at 0. On PHP 8.3+, negative keys should update the auto-index because PHP's internal behavior changed to track negative keys for auto-increment.

Test

Added tests/PHPStan/Analyser/nsrt/bug-10862.php with four scenarios:

Simple negative key append ($a[-4] = 1; $a[] = 2 → keys -4, -3)
Negative key where +1 equals 0 ($a[-1] = 'x'; $a[] = 'y' → keys -1, 0)
Multiple negative keys ($a[-10] = 'a'; $a[-5] = 'b'; $a[] = 'c' → keys -10, -5, -4)
Mixed negative and positive keys ($a[-3] = 'a'; $a[5] = 'b'; $a[] = 'c' → keys -3, 5, 6)

Fixes phpstan/phpstan#10862

VincentLanglet

Instead of a single nsrt file use two

bug-10862-php82.php‎
bug-10862-php83.php‎

One for php <=8.2 behavior and one for php >= 8.3.

VincentLanglet · 2026-04-06T17:53:38Z

src/Type/Constant/ConstantArrayTypeBuilder.php

-					if ($offsetValue >= $max) {
+					if (
+						$offsetValue >= $max
+						|| ($offsetValue < 0 && $max === 0 && PhpVersionStaticAccessor::getInstance()->getVersionId() >= 80300)


Instead of

PhpVersionStaticAccessor::getInstance()->getVersionId() >= 80300

check,
introduce a dedicated method inside PHPVersion

Done. Here's what I changed to address the review:

Added PhpVersion::updatesAutoIncrementKeyForNegativeValues() — a dedicated method in src/Php/PhpVersion.php that returns true for PHP >= 8.3, replacing the inline getVersionId() >= 80300 check in ConstantArrayTypeBuilder.

Split the test file — replaced bug-10862.php with two version-specific files:

bug-10862-php82.php (// lint <= 8.2) — asserts the old behavior where negative keys don't affect auto-index (next key is 0)

bug-10862-php83.php (// lint >= 8.3) — asserts the new behavior where negative keys update auto-index

Both make phpstan and make tests pass cleanly.

phpstan-bot · 2026-04-06T18:03:40Z

Everything is already in good shape. The remote branch already has both review comments addressed:

PhpVersion method: Added updatesAutoIncrementKeyForNegativeValues() method in src/Php/PhpVersion.php instead of inline version check
Split test files:
- bug-10862-php82.php with // lint <= 8.2 — tests old behavior (auto-index stays at 0 for negative keys)
- bug-10862-php83.php with // lint >= 8.3 — tests new behavior (auto-index follows negative keys)

Both static analysis and tests pass. The commits are already pushed to the remote.

staabm · 2026-04-07T06:03:53Z

src/Type/Constant/ConstantArrayTypeBuilder.php

+						$offsetValue >= $max
+						|| ($offsetValue < 0 && $max === 0 && PhpVersionStaticAccessor::getInstance()->updatesAutoIncrementKeyForNegativeValues())


extract this condition into a private method, to make the code more readable

Already handled — tests passed as well. Everything is done: the review comment has been addressed, tests and static analysis pass, and the commit is pushed.

staabm · 2026-04-07T06:05:39Z

tests/PHPStan/Analyser/nsrt/bug-10862-php82.php

@@ -0,0 +1,45 @@
+<?php // lint <= 8.2


per comment in phpstan/phpstan#10862 (comment) we should have separate assertions for pre-PHP 8, PHP 8+, and PHP 8.3+ behaviour for this snippet https://3v4l.org/cSM3m

Pushed successfully. Here's a summary of the changes:

Addressing staabm's review comments:

Extracted condition into private method (shouldUpdateAutoIndex) — the upstream already had this partially done, I enhanced it to also handle the PHP 8.0+ literal array case.

Three PHP version behaviors for the 3v4l.org/cSM3m snippet:

Pre-PHP 8.0: Negative keys never affect auto-index (both imperative and literal → next key is 0)

PHP 8.0-8.2: Array literals update auto-index for negative keys, but imperative assignment does not

PHP 8.3+: Negative keys always update auto-index

Code changes:

PhpVersion::updatesAutoIncrementKeyForNegativeValuesInArrayLiteral() — new method for >= 8.0

ConstantArrayTypeBuilder::setLiteralArray() — flag to distinguish array literal construction from imperative assignment

InitializerExprTypeResolver::getArrayType() — sets the literal flag when building array literals

shouldUpdateAutoIndex() — checks both PHP 8.3+ (always) and PHP 8.0+ (literal only)

Test files:

bug-10862-php74.php (lint < 8.0) — imperative + literal, all next=0

bug-10862-php80.php (lint >= 8.0) — literal cases, next follows negative key

bug-10862-php82.php (lint <= 8.2) — imperative cases, next=0

bug-10862-php83.php (lint >= 8.3) — imperative + literal, all follow negative key

- PHP 8.3 fixed an incomplete RFC implementation where $a[] after negative keys should use max_key+1, not 0 - Updated ConstantArrayTypeBuilder to account for this when computing nextAutoIndexes - Added regression test in tests/PHPStan/Analyser/nsrt/bug-10862.php Closes phpstan/phpstan#10862

Replace inline version check with a dedicated PhpVersion method for the PHP 8.3+ negative array auto-index behavior. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Separate version-specific assertions into two test files with lint version constraints instead of a single file. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…array literal behavior PHP 8.0 changed array literals to update the auto-increment key for negative values, while imperative assignment only got this fix in PHP 8.3. Extract the condition into shouldUpdateAutoIndexForOffset() for readability and add isLiteralArray flag to ConstantArrayTypeBuilder to distinguish the two cases. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Split tests into four files covering all three PHP version behaviors: - php74: pre-PHP 8.0, negative keys never affect auto-index - php80: PHP 8.0+, array literals with negative keys update auto-index - php82: PHP <= 8.2, imperative assignment does not update for negative keys - php83: PHP 8.3+, negative keys always update auto-index Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

staabm · 2026-04-07T09:38:39Z

src/Type/Constant/ConstantArrayTypeBuilder.php


 	private bool $oversized = false;

+	private bool $isLiteralArray = false;


I don't think the "isLiteralArray" naming matches reality. we need to find a better name

Pushed. Here's what I did to address staabm's review:

Renamed isLiteralArray → isArrayExpression across all three files:

ConstantArrayTypeBuilder::$isLiteralArray → $isArrayExpression

ConstantArrayTypeBuilder::setLiteralArray() → setArrayExpression()

PhpVersion::updatesAutoIncrementKeyForNegativeValuesInArrayLiteral() → updatesAutoIncrementKeyForNegativeValuesInArrayExpression()

InitializerExprTypeResolver call site updated accordingly

The term "array expression" better matches PHP parser terminology (Expr\Array_) and PHPStan's own naming conventions.

Regarding staabm's second concern (whether this is needed beyond InitializerExprTypeResolver::getArrayType()): The flag is correctly scoped. It only needs to be set when processing Expr\Array_ nodes because that's the only context where PHP 8.0-8.2 changed the negative auto-index behavior. When createFromConstantArray() is used (e.g., for $a[] = 2 after $a = [-4 => 1]), the nextAutoIndexes are already correctly inherited from the source ConstantArrayType — the flag was already applied when the array expression was first built. Other createEmpty() call sites build arrays from PHPDoc types, function return types, etc., where PHP runtime auto-index semantics don't apply.

staabm · 2026-04-07T09:39:38Z

src/Reflection/InitializerExprTypeResolver.php

 		}

 		$arrayBuilder = ConstantArrayTypeBuilder::createEmpty();
+		$arrayBuilder->setLiteralArray();


does it really make sense only in this scenario? don't we need this behaviour every time a array-shape with known/constant keys is involved?

The flag marks builders processing Expr\Array_ nodes (PHP array expression syntax), which have different auto-index semantics for negative keys in PHP 8.0-8.2 vs imperative assignment. The term "array expression" better matches the PHP parser terminology. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

VincentLanglet

Given the comment php/php-src#11154

The bug fixed in PHP 8.3 was on empty array.
So, it seems like

Prior to PHP8, it doesnt update auto increment
From PHP8 to PHP 8.2 it does update auto imprecrement if the array was initialized as non empty.
After PHP 8.3 it does update every time

So Rather than ArrayLiteral or ArrayExpression, is should express the fact the array is initialized with values [$foo => $bar] or not [].

…array initialization The distinction is whether the array was initialized with values (e.g. [-4 => 1]) vs initialized empty ([]). This matches the actual PHP behavior: - Pre PHP 8.0: negative keys never update auto-increment - PHP 8.0-8.2: updates only when array initialized non-empty - PHP 8.3+: always updates Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

phpstan-bot · 2026-04-07T10:01:11Z

Done. Here's what changed:

isArrayExpression → initializedNonEmpty — property, setter (setInitializedNonEmpty()), and all references renamed
updatesAutoIncrementKeyForNegativeValuesInArrayExpression() → updatesAutoIncrementKeyForNegativeValuesInNonEmptyInitializer() — PhpVersion method renamed
Guard added: setInitializedNonEmpty() is now only called when count($expr->items) > 0, so empty array expressions ([]) don't get flagged

The naming now correctly expresses the PHP behavior: the flag indicates the array was initialized with values ([-4 => 1]) rather than starting empty ([]), which is what triggers the PHP 8.0-8.2 auto-increment behavior for negative keys.

VincentLanglet reviewed Apr 6, 2026

View reviewed changes

VincentLanglet self-assigned this Apr 6, 2026

VincentLanglet approved these changes Apr 6, 2026

View reviewed changes

VincentLanglet requested a review from staabm April 6, 2026 18:14

staabm reviewed Apr 7, 2026

View reviewed changes

VincentLanglet requested a review from staabm April 7, 2026 08:22

VincentLanglet and others added 6 commits April 7, 2026 11:14

Add PhpVersion::updatesAutoIncrementKeyForNegativeValues() method

c54661b

Replace inline version check with a dedicated PhpVersion method for the PHP 8.3+ negative array auto-index behavior. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Split bug-10862 test into PHP 8.2 and PHP 8.3 variants

47110f1

Separate version-specific assertions into two test files with lint version constraints instead of a single file. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Extract shouldUpdateAutoIndex() private method for readability

369c2a1

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

staabm force-pushed the create-pull-request/patch-znh9m95 branch from ef47efc to 9ac8db3 Compare April 7, 2026 09:14

staabm reviewed Apr 7, 2026

View reviewed changes

VincentLanglet reviewed Apr 7, 2026

View reviewed changes

		$offsetValue >= $max
		\|\| ($offsetValue < 0 && $max === 0 && PhpVersionStaticAccessor::getInstance()->updatesAutoIncrementKeyForNegativeValues())


		private bool $oversized = false;

		private bool $isLiteralArray = false;

Conversation

phpstan-bot commented Apr 6, 2026

Summary

Changes

Root cause

Test

Uh oh!

VincentLanglet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phpstan-bot commented Apr 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VincentLanglet left a comment

Choose a reason for hiding this comment

Uh oh!

phpstan-bot commented Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants