Do not treat conditional-expression entries about a property fetch as proof it is initialized

[phpstan-bot]

Summary

$this->foo ?? null was reported as nullCoalesce.unnecessary ("Coalesce operator ?? is unnecessary because the left side is always set and the right side is null.") when the typed property $this->foo had only been conditionally initialised earlier in the same scope — even though it may still be uninitialised at that point.

The check that decides whether the left side of ?? is always set now no longer treats the mere presence of conditional-expression entries about a property fetch as proof that the property is initialised.

Changes

• src/Analyser/IssetabilityResolution.php — removed the !$link->hasConditionalExpressionsOfFetch() clause from the property branch of isSet(), restoring exact parity with MutatingScope::issetCheck().
• src/Analyser/IssetabilityLinkInfo.php — removed the now-unused hasConditionalExpressionsOfFetch constructor parameter, factory argument and getter.
• src/Analyser/IssetabilityDescriptor.php — stopped computing isset($scope->getConditionalExpressions()[$scope->getNodeKey($propertyFetch)]).
• tests/PHPStan/Rules/Variables/data/bug-15046.php, tests/PHPStan/Rules/Variables/NullCoalesceRuleTest.php — regression test.

Analogous cases that reproduced the same false positive and are fixed by the same change (all covered by the new test data file):

• static properties (self::$answer ?? null)
• a plain bool condition instead of a !== null narrowing
• ??= ($this->answer ??= null)
• conditional assignment via a ternary
• conditional assignment inside a switch branch
• nested chains ($this->inner->deep ?? null)

Probed and found already correct, so no test was kept for them:

• isset() and empty() on a conditionally initialised property — these render through Rules\IssetCheck::doCheck(), which never consulted conditional expressions.
• The inferred types of $this->answer ?? null, isset($this->answer) and empty($this->answer) — computed by MutatingScope::issetCheck(), which also never consulted conditional expressions.
• Conditional assignment inside try/catch, while and for — these do not produce conditional-expression entries.
• Hooked and promoted-readonly properties — still correctly reported as always set.

Root cause

IssetabilityResolution::isSet() is the fold that NullCoalesceRule::checkUnnecessaryNullCoalesce() uses to decide whether the left side of ?? is always set. Its property branch normally answers "maybe" for a typed property with no default value, because such a property can be uninitialised. That branch was skipped whenever $scope->getConditionalExpressions() held entries keyed by the property fetch, documented with the rationale that such entries "exist only when the fetch was narrowed in an evaluated condition — and evaluating a condition READS the fetch, which would have thrown on an uninitialized typed property".

That premise is wrong. AssignHandler also records conditional expressions for a property that is assigned inside a conditional branch, so:

if ($my_answer !== null) {
    $this->answer = $my_answer;
}
// scope now holds: if $my_answer=int then $this->answer is int
echo $this->answer ?? null; // ← reported as unnecessary

produced exactly the entries the clause interpreted as "witnessed initialisation", and the fold answered "always set".

The clause was introduced in ac92f19c8 ("Resolve isset/empty/?? chains from handler-built descriptors", released in 2.2.8) when MutatingScope::issetCheck()'s chain walk was reimplemented on top of IssetabilityDescriptor; neither MutatingScope::issetCheck() nor Rules\IssetCheck has ever had it. Dropping it restores the three implementations to the same semantics. The scenario the clause was meant to cover still works: reading a property inside a condition puts a real ExpressionTypeHolder for the fetch into the scope, which the pre-existing hasExpressionTypeOfFetch() check already handles.

Test

tests/PHPStan/Rules/Variables/data/bug-15046.php contains the reporter's playground snippet verbatim plus the analogous constructs listed above, and two control cases that must keep reporting: a property assigned in both branches of an if/else (nullCoalesce.initializedProperty) and a fetch inside a second if where the same condition holds again (nullCoalesce.property).

Without the fix the test fails with seven nullCoalesce.unnecessary false positives (lines 14, 34, 50, 66, 80, 98, 122); with the fix only the two control errors remain.

Full make tests and make phpstan are green.

Fixes phpstan/phpstan#15046