Merge scope after ?-> method call to account for argument short-circuiting

[phpstan-bot]

Summary

PHP's nullsafe operator ?-> short-circuits evaluation when the left operand is null, meaning method arguments are not evaluated. PHPStan was not accounting for this: variables assigned within nullsafe method call arguments were treated as "definitely defined" even though they might not be evaluated at all.

Changes

• Modified src/Analyser/ExprHandler/NullsafeMethodCallHandler.php:
  • Save the scope before processing the nullsafe method call
  • After processing, if the var type is always null, use the pre-call scope (arguments are never evaluated)
  • If the var type is nullable (but not always null), merge the post-call scope with the pre-call scope so that variables assigned in arguments become "maybe defined"
  • If the var type is never null, no merging is needed (existing behavior preserved)

Root cause

NullsafeMethodCallHandler::processExpr() converts $date?->format($format = "Y-m-d") into a regular MethodCall and processes it unconditionally. This means $format gets added to the scope as "definitely defined". But in PHP, when $date is null, the entire method call including argument evaluation is short-circuited — $format is never assigned.

The fix mirrors how CoalesceHandler and BooleanAndHandler already handle conditional evaluation: by merging the scope from the "executed" path with the scope from the "not executed" path, making any newly-introduced variables "maybe defined".

Analogous cases probed:

• NullsafePropertyFetchHandler: Property names are almost always Identifier nodes (not expressions), so there are no side effects to short-circuit. The rare case of $obj?->$name where $name has side effects is theoretical — skipped.
• Chained nullsafe calls ($a?->b()?->c($x = 1)): Each ?-> is a separate NullsafeMethodCall node, so the fix applies independently at each level — works correctly.
• Named arguments, nested assignments in arguments: Covered by the same merge logic since all arguments are processed within the MethodCall.

Test

• tests/PHPStan/Rules/Variables/data/bug-10729.php — DefinedVariableRule test covering:
  • Nullable var: $format reported as "might not be defined" (the reported bug)
  • Non-nullable var: no error (control case)
  • Always-null var: $format reported as "Undefined variable" (arguments never evaluated)
  • Multiple arguments: both $format and $value reported as "might not be defined"
  • Nested assignment: $result = $date?->format($format = ...) with $format correctly "might not be defined"
  • Existing variable preservation: variables defined before the nullsafe call remain "definitely defined"
• tests/PHPStan/Analyser/nsrt/bug-10729.php — Type inference test verifying correct types for variables assigned in nullsafe arguments

Fixes phpstan/phpstan#10729