Report how a sealed/unsealed array shape treats undeclared keys even when an offset check already failed

[phpstan-bot]

Summary

A return/argument/assignment rejected by a sealed array shape sometimes came with the
Sealed array shape can only accept a constant array. Extra keys are not allowed. tip and
sometimes with no tip at all. The difference was whether the per-offset check inside
ConstantArrayType::accepts() had already produced a definite no: if it had, accepts()
returned early and never reached the sealedness check — and since that per-offset check adds
no reason when the accepted type is not a constant array, the error ended up with no
explanation at all.

The fix moves the undeclared-keys check ahead of the early bail-out, gives the unsealed
counterpart the same treatment, and reports a reason shared by all members of a union only
once instead of repeating it per member.

Changes

• src/Type/Constant/ConstantArrayType.php
  • accepts(): the "how does this shape treat keys it does not declare" check now runs
    before if ($result->no()) return $result;, so the sealed tip survives an already-failing
    offset check. Guarded with !$type->isArray()->no() so passing e.g. a string to an array
    shape is not annotated with an array-specific tip.
  • accepts(): the unsealed branch for non-constant arrays (array{a: string, ...<int>} vs
    array<string, bool>) was subject to the same bail-out and, when reached, and()-ed in
    bare reason-less results. It now reports
    Unsealed array key type <K> does not accept key type <K2>. /
    Unsealed array value type <V> does not accept value type <V2>.
  • accepts(): the count($this->keyTypes) === 0 shortcut returned
    AcceptsResult::createFromBoolean(...), i.e. a no with no reasons. array{} now lists
    the extra keys just like the non-empty sealed branch does
    (Sealed array shape does not accept array with extra key 'a'.).
  • Extracted decorateUnsealedReasons(), replacing four copies of the same
    decorate-inner-reasons-or-synthesize-one block.
• src/Type/UnionType.php
  • accepts(): when every member of the union fails for the same reason, that reason is
    reported once instead of once per member with a Type #N from the union prefix.
• Tests: tests/PHPStan/Rules/Methods/ReturnTypeRuleTest.php +
  tests/PHPStan/Rules/Methods/data/bug-15234.php,
  tests/PHPStan/Type/Constant/ConstantArrayTypeTest.php,
  tests/PHPStan/Rules/Properties/TypesAssignedToPropertiesRuleTest.php.

Root cause

The pattern is an explanatory reason being short-circuited by a sub-check that fails first.
ConstantArrayType::accepts() is layered: checkOurKeys() validates the declared offsets,
then the sealed/unsealed part validates everything the shape does not declare. The second
layer was only reached when the first one had not already returned no. Because
checkOurKeys() deliberately omits reasons for non-constant arrays ($type->isConstantArray()->yes()
gates both of its reason strings), that combination produced a rejection with zero reasons —
exactly the reported case, where non-empty-array<string, mixed>&hasOffsetValue('functions', …)
failed on the functions offset and thus never got the sealed tip.

The two layers are independent: sealedness rejects the type regardless of whether the declared
offsets happen to match, so it belongs before the bail-out, not after. Every location that had
this shape was fixed:

• sealed shape vs non-constant array (the reported case),
• unsealed shape vs non-constant array (same code path, unsealed branch),
• sealed array{} vs a shape with extra keys (separate early createFromBoolean() shortcut).

IntersectionType::accepts() was probed and is already correct — it accumulates with and()
and never short-circuits. UnionType::isSuperTypeOf() has no per-member reason decoration, so
it has no equivalent of the duplication fixed in UnionType::accepts().

Test

• ReturnTypeRuleTest::testBug15234 analyses the reporter's playground snippet verbatim and
  asserts all three tips, including the previously missing one on queryDeviceFunctions() and
  the now-deduplicated union tip on queryDeviceSignalStrength(). It fails on 2.2.x with a
  missing tip on one line and a doubled tip on another.
• ConstantArrayTypeTest::testAccepts gained cases for the analogous constructs, each of which
  fails without the fix:
  • sealed shape vs a general array whose value type already mismatches,
  • sealed shape vs non-empty-array<…>&hasOffsetValue(…) (the reduced form of the report),
  • unsealed shape vs a general array with an incompatible key type,
  • and the two existing cases that asserted the reason-less behaviour
    (array{} vs array{a: string}, unsealed shape vs incompatible general array) were
    updated to the corrected output.
• TypesAssignedToPropertiesRuleTest::testBug13438d/e now assert the
  Sealed array shape does not accept array with extra key 0. tip, which shows the same fix
  reaching property assignment; parameter passing was verified manually to gain the tip too
  (both go through the same accepts()).

Fixes phpstan/phpstan#15234

[VincentLanglet]

Revert the change to the UnionType, this is un unrelated issue ; focus only on the missing tip about array sealed.

[phpstan-bot]

Done — pushed as 6cd040194.

What changed:

• src/Type/UnionType.php reverted to its pre-PR state; accepts() again prefixes a reason shared by all union members with Type #N from the union once per member. The PR now touches only ConstantArrayType::accepts().
• ReturnTypeRuleTest::testBug15234 updated accordingly: the tip on line 30 (queryDeviceSignalStrength()) is back to the two-bullet repeated form. The other two expectations — including the previously missing tip on line 62, which is what the issue is about — are unaffected.

Verification: make tests passes (21382 tests, 92 skipped, 0 failures) and make phpstan reports no errors.