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