Narrow the right side of ??= with falsey isset() instead of !== null

[phpstan-bot]

Summary

$data['foo'] ??= $data['bar'] ?? null; on array{foo?: string, bar?: string} reported a bogus error — Coalesce operator ?? is unnecessary because the left side is always set and the right side is null. with treatPhpDocTypesAsCertain: false, and Offset 'bar' on *NEVER* on left side of ?? always exists and is not nullable. with it enabled. Both messages come from the same cause: while analysing the right-hand side of ??=, PHPStan narrowed $data down to *NEVER*.

The fix builds the right-hand-side scope from the actual ??= short-circuit condition (!isset($var)) instead of from $var === null.

Changes

• src/Analyser/ExprHandler/AssignOpHandler.php — in processExpr(), the scope for $expr->expr is now $scope->filterByFalseyValue(new Expr\Isset_([$expr->var])) instead of $scope->filterByFalseyValue(new BinaryOp\NotIdentical($expr->var, new ConstFetch(new Name('null')))). Removed the now-unused ConstFetch / Name imports.
• tests/PHPStan/Rules/Variables/data/bug-15021.php + NullCoalesceRuleTest::testBug15021() — the reproducer from the issue, expecting no errors.
• tests/PHPStan/Rules/Variables/data/null-coalesce-assign-right-side-scope.php + NullCoalesceRuleTest::testNullCoalesceAssignRightSideScope() — the analogous left-hand-side forms.
• tests/PHPStan/Analyser/nsrt/bug-15021.php — type-level assertions for every form.

Analogous cases fixed by the same change (each has a failing-before test):

• optional array offset — array{foo?: string, bar?: string}, the reported case
• non-constant array with a constant key — array<string, string>, previously non-empty-array<string, string>&hasOffsetValue('foo', *NEVER*)
• non-constant array with nullable values — array<string, string|null>, right side saw null, now string|null (matching plain ??)
• nested array offset — $data['a']['b'] ??= … on array{a?: array{b?: string, c?: string}}
• non-nullable instance property — $foo->nonNullable ??= …
• non-nullable static property — Foo::$staticNonNullable ??= …
• array offset on a property — $foo->data['foo'] ??= …
• undefined variable — $undefined ??= $undefined ?? 1 reported Variable $undefined on left side of ?? always exists and is always null., now correctly … is never defined.

Sibling constructs probed and found already correct, so left untouched:

• src/Analyser/ExprHandler/CoalesceHandler.php — both resolveType() and processExpr() derive the right-side scope from the isset/coalesce condition, not from !== null
• src/Analyser/ExprHandler/IssetHandler.php, src/Analyser/ExprHandler/EmptyHandler.php — already model "not set or null"
• src/Analyser/ExprHandler/NullsafePropertyFetchHandler.php, NullsafeMethodCallHandler.php — these use a truthy !== null filter, which is the correct semantics for ?-> (the object must be non-null), not a coalesce-style short circuit

Root cause

??= evaluates its right-hand side when the target is either unset or null. AssignOpHandler modelled only the second half by filtering the scope with the falsey value of $var !== null, i.e. asserting $var === null.

For every target whose type cannot hold null — an optional array offset typed string, a non-nullable property, an array<string, string> value — that assertion is unsatisfiable, so TypeSpecifier propagated the contradiction outwards and turned the containing expression into never: the whole $data array, the whole object, etc. Every rule and type query on the right-hand side then operated on *NEVER*, producing either cascading nonsense messages (Offset 'bar' on *NEVER' …) or, when PHPDoc types were not treated as certain, the "coalesce is unnecessary" verdict.

Using filterByFalseyValue(new Isset_([$var])) states the real condition. IssetHandler::specifyTypes() already knows how to narrow !isset(...) conservatively — it only removes a constant array when the offset is definitely set and definitely non-null (which is genuinely unreachable code), and it leaves possibly-missing offsets alone. This is also the exact condition CoalesceHandler::resolveType() uses for the right side of ??, so ??= and ?? now agree.

Test

• NullCoalesceRuleTest::testBug15021() — verbatim reproducer from the issue's playground link; expects no errors. Fails before the fix with Offset 'bar' on *NEVER* on left side of ?? always exists and is not nullable.
• NullCoalesceRuleTest::testNullCoalesceAssignRightSideScope() — covers property, static property, property offset, nested offset, non-constant array and undefined-variable targets. Before the fix it produced two extra Offset … on *NEVER* errors and the wrong message for the undefined variable.
• tests/PHPStan/Analyser/nsrt/bug-15021.php — assertType() on the right-hand-side scope for all of the above; 7 assertions fail before the fix (5 of them *NEVER*).

Full make tests, make phpstan and make cs-fix are green.

Fixes phpstan/phpstan#15021

[staabm]

Is offset access with ?? and ArrayAccess or ArrayObject covered in tests?

[phpstan-bot]

While that finishes, here's a summary of what I've done so far.

The reviewer's question was well-founded — ArrayAccess/ArrayObject offsets were not covered, and the fix genuinely changes their behavior. I verified this by reverting the source change and re-running:

case (right side of ??=)	before fix	after fix	plain ??
ArrayAccess<string, string>, $a['foo']	*NEVER*	string	string
ArrayAccess<string, string|null>, $a['foo']	null	string|null	string|null
ArrayObject<string, string>, $data['foo']	null	string|null	string|null

Same root cause as the reported bug: for ArrayAccess the container isn't collapsed to *NEVER* (the offset is method-call-backed), but the offset expression is — because $a['foo'] === null is unsatisfiable when offsetGet() returns non-nullable string. After the fix ??= and ?? agree in every case.

At rule level there's also a bogus error, when the same offset appears on both sides:

$a['foo'] ??= $a['foo'] ?? null;
// before: Offset 'foo' on …\NonNullableOffsetAccess on left side of ?? always exists and is not nullable.
// after:  no error

That message is exactly backwards — the inner ?? sits in the scope where $a['foo'] is unset-or-null.

Tests added (each verified failing before the fix, passing after):

• nsrt/bug-15021.php — 9 functions covering the container type, the offset value, and a plain-?? counterpart for each of the three container kinds. Assertions on lines 128, 139, 156 fail before the fix.
• data/null-coalesce-assign-right-side-scope.php — 6 rule-level functions (different-offset and same-offset forms for non-nullable ArrayAccess, nullable ArrayAccess, ArrayObject). Line 107 reports the bogus error before the fix.

Two notes on things I hit along the way:

• Existing expectations in NullCoalesceRuleTest shifted by 3 lines because I added use ArrayAccess; use ArrayObject; to the data file.
• My first version used mixed $offset params, which failed RequiredPhpVersionCommentTest (it wants a // lint >= 8.0 marker). I dropped the param types instead of adding the marker, so both fixtures keep running on every PHP version in CI rather than being skipped on older ones.

make phpstan and make cs are clean; full make tests is running now, then I'll commit and push.

[staabm]

add those tests for ArrayAccess and ArrayObject