Internal error Int_::__construct(): Argument #1 ($value) must be of type int, float given when assigning an array literal with key 9223372036854775807 followed by a keyless or unpacked item #15248

Bug report

Assigning an array literal to a variable crashes the analysis of the whole file when:

• the literal has the explicit key 9223372036854775807 (PHP_INT_MAX), and
• a later item has no key, including an unpacked ...$rest item.

The code below is valid at runtime (PHP 8.1+ string-key unpacking) and produces [PHP_INT_MAX => 1, 'k' => 2, 'x' => 3]:

/**
 * @param array<string, int> $rest
 * @return array<int|string, int>
 */
function foo(string $key, array $rest): array
{
	$a = [9223372036854775807 => 1, $key => 2, ...$rest];

	return $a;
}

Internal error: PhpParser\Node\Scalar\Int_::__construct(): Argument #1 ($value) must be of type int, float given, called in src/Analyser/ExprHandler/AssignHandler.php

Mechanism (line numbers from 2.3.x):

• AssignHandler calls processArrayByRefItems() for every $variable = [array literal] assignment, not only for literals that contain &$ref items (AssignHandler.php:1342).
• For each item, the method computes the key the item will get. After an explicit constant integer key it sets $implicitIndex = $keyValue + 1; (L2529). For PHP_INT_MAX that overflows to a float.
• The next item without a key gets new Node\Scalar\Int_($implicitIndex) (L2540), which throws the TypeError.
• Unpacked items (...$rest) also go through this branch, because their key is null.

This is separate from the DuplicateKeysInLiteralArraysRule crash on [9223372036854775807 => 1, 2]. That rule stops tracking implicit keys at the $key item, whose key type has no constant value. Returning the same literal directly (return [9223372036854775807 => 1, $key => 2, ...$rest];) is analysed without errors. Only the assignment crashes.

The same code is in 2.2.x, so the crash also reproduces on the playground.

Code snippet that reproduces the problem

https://phpstan.org/r/adddb02b-70ce-4280-83c1-6c92b16e1914

Expected output

No internal error, and no errors at all for this snippet.

Suggested fix in processArrayByRefItems():

• When the explicit key is PHP_INT_MAX, stop tracking implicit indices ($implicitIndex = null;) instead of computing $keyValue + 1.
• Treat an unpacked item ($arrayItem->unpack) as shifting the next index by an unknown amount: set $implicitIndex = null; and skip the item. At the moment it is counted as a single keyless item, so by-reference items that follow a spread, as in [...$list, &$x], are linked to the wrong offset (reported separately in By-reference item after a spread in an array literal ([...$list, &$x]) is linked to the wrong offset #15247).

With these two changes the snippet above is analysed without errors. So is the runtime-invalid $a = [9223372036854775807 => 1, $key => 2, 3];, which crashes in the same place today.

Did PHPStan help you today? Did it make you happy in any way?

No response