Resolve array offset access on never to never and treat never operands of ===/!== as undecided

[phpstan-bot]

Summary

An impossible identical comparison inside assert() over a constant array — e.g. assert($array[1] === null) where $array[1] is 0 — collapses the whole array to never (which is correct). The bug was that the following statements then produced a cascade of spurious Strict comparison using === between *NEVER* and null will always evaluate to false. errors, and that reading a further offset of the now-never array produced an *ERROR* type instead of never.

This was the regression behind the revert of d7ba1e3 ("More precise array-item types in loops"). This change fixes the root cause so the precision improvement no longer produces the cascade.

Changes

• src/Analyser/ExprHandler/ArrayDimFetchHandler.php — short-circuit resolveType() when the offset-accessible type is NeverType, returning never. Previously, because never is a subtype of everything (including ArrayAccess), the fetch was routed through offsetGet() and produced *ERROR*.
• src/Reflection/InitializerExprTypeResolver.php — resolveIdenticalType() now returns a non-constant BooleanType (instead of ConstantBooleanType(false)) when either operand is never, so ===/!== no longer reports always-true/false on already-unreachable code.
• tests/PHPStan/Analyser/data/bug-9307.php — the loop case now correctly infers array<int, Bug9307\Item> instead of array<*ERROR*> (the inline comment already predicted this).
• tests/PHPStan/Rules/Comparison/StrictComparisonOfDifferentTypesRuleTest.php — the last-match-arm expectations drop the two *NEVER* === 'ccc' reports, plus a new testBug14281.
• Added regression tests tests/PHPStan/Analyser/nsrt/bug-14281.php and tests/PHPStan/Rules/Comparison/data/bug-14281.php.

Root cause

Two independent spots mishandled never:

1. Offset read on never. ArrayDimFetchHandler checks (new ObjectType(ArrayAccess::class))->isSuperTypeOf($type)->yes() to decide whether to call offsetGet(). never satisfies that test (it is a subtype of every type), so an offset read on a never array was treated as an ArrayAccess::offsetGet() call and yielded *ERROR*. NeverType::getOffsetValueType() already returns never; the handler just never reached it.

2. Identical comparison with a never operand. resolveIdenticalType() returned a constant false, which the StrictComparisonOfDifferentTypesRule / ImpossibleCheckType* rules report as "always false". A never operand denotes unreachable code that carries no comparable value, so the result should be undecided — consistent with how never already behaves as a boolean condition (if, &&, ||) and with NeverType::looseCompare() for ==/!=.

Test

• nsrt/bug-14281.php asserts that after assert($array[1] === null) the array is *NEVER*, that $array[2] is *NEVER* (not *ERROR*), and that $i === null / $i !== null on a never variable are inferred as bool. It fails without the fix (Actual: *ERROR* and constant-boolean results).
• Rules/Comparison/data/bug-14281.php + testBug14281 confirm the rule only reports the genuinely-impossible first comparisons (null === null, 0 === null, int !== int) and no longer reports the unreachable *NEVER* === null / *NEVER* !== null follow-ups.
• Probed analogous comparisons: ==/!= already produce a non-constant boolean via NeverType::looseCompare(); <=>/</> produce never without an always-true/false report. No change needed for those.

Fixes phpstan/phpstan#14281

[staabm]

resolve conflicts and rebase

[staabm]

we need this errors to stay

[staabm]

revert this part

[phpstan-bot]

Done. Here's a summary of how I addressed the review.

What the reviewer asked

1. "revert this part" — the InitializerExprTypeResolver::resolveIdenticalType() change that returned a non-constant BooleanType for never operands.
2. "we need this errors to stay" (earlier comment) — the *NEVER* === 'ccc' always-false reports removed from the match-arm test.

Changes made

• src/Reflection/InitializerExprTypeResolver.php — reverted resolveIdenticalType() back to return new TypeResult(new ConstantBooleanType(false), []) for never operands. The ArrayDimFetchHandler fix (offset access on never → never instead of *ERROR*) is untouched, since the review only targeted the resolver.
• StrictComparisonOfDifferentTypesRuleTest.php — restored the two *NEVER* === 'ccc' (line 38) error expectations in dataLastMatchArm, and updated testBug14281 to expect the always-false/true reports that reappear on the unreachable comparisons.
• tests/PHPStan/Rules/Comparison/data/bug-14281.php — corrected the now-inaccurate comments (the comparisons on the collapsed-to-never array are reported again) instead of leaving the false "must not be reported" claim.
• tests/PHPStan/Analyser/nsrt/bug-14281.php — updated neverVariable expectations from bool to the actual false/true constant results; the array-offset assertions (the remaining real fix) are unchanged.

I empirically confirmed the reverted behavior via the failing/passing tests rather than guessing line numbers.

Verification

• testBug14281, testLastMatchArm, bug-14281 nsrt, and bug-9307 — all pass.
• Full tests/PHPStan/Rules/Comparison/ (426) and NodeScopeResolverTest (1679) — all green.
• make phpstan — no errors.

Committed as a single logical change and pushed to create-pull-request/patch-20i99q4.

One thing worth flagging for the reviewer: with the resolver reverted but the ArrayDimFetchHandler fix kept, offset reads on a collapsed-to-never array now produce genuine never (correct), which the strict-comparison rule then reports as always-false on the deeply-unreachable follow-up statements. That's why testBug14281 gained the extra *NEVER* === null expectations — the reproducer now emits more reports on unreachable code than before, which is the opposite of the issue's "no errors" goal. If that cascade is undesirable, the two changes may need to move together rather than splitting them.