Fix phpstan/phpstan#3831: Comparison operation ">" between 0 and 0 is always false#5147
Closed
phpstan-bot wants to merge 1 commit intophpstan:2.1.xfrom
Closed
Fix phpstan/phpstan#3831: Comparison operation ">" between 0 and 0 is always false#5147phpstan-bot wants to merge 1 commit intophpstan:2.1.xfrom
phpstan-bot wants to merge 1 commit intophpstan:2.1.xfrom
Conversation
…method call
- Dynamic method calls like $this->{'compileSection'}() did not invalidate
tracked expression types on the called object, causing properties set before
the call (e.g. $this->footer = []) to retain their narrowed types
- Added invalidateAllOnExpression() to MutatingScope that clears tracked
expression types (property fetches, method call results) without clearing
conditional type narrowing
- New regression test in tests/PHPStan/Rules/Comparison/data/bug-3831.php
Contributor
|
@VincentLanglet please make sure to remove branches on the phpstan-src repo after merging/closing PRs |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When a dynamic method call like
$this->{'compileSection'}()was used, PHPStan did not invalidate tracked expression types on the called object. This caused false positives where properties assigned before the call (e.g.,$this->footer = []) retained their narrowed types, leading to incorrect "always false" comparison errors likeComparison operation ">" between 0 and 0 is always false.Changes
invalidateAllOnExpression()method tosrc/Analyser/MutatingScope.php— a targeted invalidation that clears tracked expression types (property fetches, method call results) on the given expression without clearing conditional type narrowing informationsrc/Analyser/ExprHandler/MethodCallHandler.phpto callinvalidateAllOnExpression()on the receiver when processing a dynamic method call (where$expr->nameis anExpr)tests/PHPStan/Rules/Comparison/data/bug-3831.phpand corresponding test method inNumberComparisonOperatorsConstantConditionRuleTestRoot cause
In
MethodCallHandler, when the method name is dynamic ($this->{'name'}()),$methodReflectionisnullbecause PHPStan cannot resolve the method statically. The existing code only invalidated expressions in the$methodReflection !== nullbranch (when side effects were detected), so theelsebranch for unknown methods only added an implicit throw point without invalidating any tracked expression types.The fix uses a new
invalidateAllOnExpression()method instead of the existinginvalidateExpression()to avoid clearing conditional type expressions — this prevents a regression where dynamic method calls on variables with conditional types (like$a->{$method}()with conditional parameter types) would lose their type narrowing.Test
The regression test reproduces the original issue: a class with a property
$footerthat is set to[], followed by a dynamic method call that could modify it, and then acount($this->footer) > 0check that should not produce a false positive.Fixes phpstan/phpstan#3831