Fix phpstan/phpstan#9455: Bug: False report Cannot call method getId() on A|null

[phpstan-bot]

Summary

When a null check on a method call result was stored in a boolean variable (e.g., $hasA = $b->getA() !== null), and that variable was later used in an if condition, PHPStan failed to narrow the type of $b->getA() inside the branch. The inline equivalent (if ($b->getA() !== null)) worked correctly.

Changes

• Added MethodCall and Expr\StaticCall to the allowed expression types in processSureTypesForConditionalExpressionsAfterAssign() and processSureNotTypesForConditionalExpressionsAfterAssign() in src/Analyser/ExprHandler/AssignHandler.php
• Added regression test in tests/PHPStan/Analyser/nsrt/bug-9455.php

Root cause

When PHPStan processes an assignment like $hasA = $b->getA() !== null, it creates ConditionalExpressionHolder objects that record type narrowing to apply when the assigned variable is later used in a condition. However, the methods processSureTypesForConditionalExpressionsAfterAssign and processSureNotTypesForConditionalExpressionsAfterAssign only allowed Variable, PropertyFetch, ArrayDimFetch, and FuncCall expressions to create these holders — MethodCall and StaticCall were filtered out. This meant that type narrowing from method call null checks (like $b->getA() !== null) was never stored and thus never applied when the boolean variable was checked.

Test

The regression test verifies that $b->getA() is correctly narrowed to Bug9455\A (not Bug9455\A|null) inside an if ($hasA) block where $hasA = $b->getA() !== null.

Fixes phpstan/phpstan#9455
Fixes phpstan/phpstan#5207

[staabm]

add regression test for phpstan/phpstan#5207

[phpstan-bot]

Done. Added regression test tests/PHPStan/Analyser/nsrt/bug-5207.php for phpstan/phpstan#5207, which covers the same boolean-variable type narrowing bug with the exact code from that issue (abstract class with nullable getChild() method). All tests pass and PHPStan static analysis is clean.

[VincentLanglet]

Add a test with an impure method, asserting the error is still reported

[phpstan-bot]

I processed this review but have nothing to report.

[staabm]

since this change we get this error
https://phpstan.org/r/4421249a-1a56-4e0e-8b92-943c4977491d
(see integration tests)

Using nullsafe method call on non-nullable type Shopware\Core\Checkout\Customer\Service\OrderCustomerEntity. Use -> instead.

@VincentLanglet do we agree that this error is correct? if so, I would add a test for it

[VincentLanglet]

The error is correct

[ondrejmirtes]

This change is flawed, massive regressions in tested projects. See: https://phpstan.org/r/76637537-dda9-4683-afd0-7b2cd4c428f8

Reverting this for now.

[ondrejmirtes]

Makes me think that the other already existing !$expr instanceof ... might show the same problems.

[VincentLanglet]

The example you give seems legit to me @ondrejmirtes. If nullable method returns null, it is still considered as returning null later since the method is pure by default

[ondrejmirtes]

I understand the reasoning, but it throws me off because usually what I recommend to people to work around remembered "possibly impure" calls is to use variables. So I don't expect the 2nd $this->nullable() call to reuse the above check if ($device === null) {. Becomes we're comparing saved variables, not calls themselves. It surprised even me so

Maybe this "save returned call value by variable" should only work for something that's really @phpstan-pure and not just "maybe pure". But we can save this for later, maybe a solution emerges.

[VincentLanglet]

I'll reopen phpstan/phpstan#9455 then

Edit: just saw that you reopened it already but the bot reclosed it !

[ondrejmirtes]

Yeah because of "fix X" in the reverted commit message.