Fix phpstan/phpstan#14319: PHPStan takes extremely long analyzing if-offset checks on array|object#5242
Merged
VincentLanglet merged 10 commits intophpstan:2.1.xfrom Mar 18, 2026
Conversation
Contributor
|
before this PR with this PR |
staabm
reviewed
Mar 18, 2026
staabm
reviewed
Mar 18, 2026
staabm
changed the title
array|object
Contributor
|
I confirm that this fixes the issue. When using the new phar the analyse run completes in reasonable time. |
clxmstaab
force-pushed
the
create-pull-request/patch-cltr70w
branch
from
204ad22 to
718cca9
Compare
…im fetch narrowing - Added ARRAY_DIM_FETCH_UNION_TYPE_LIMIT (8) to MutatingScope to cap parent type narrowing - When array dim fetch narrows a parent variable type that is already a UnionType with more than 8 members, skip propagating HasOffsetValueType intersections to the parent - This prevents 2^N exponential growth when N consecutive if-blocks check different array offsets on an array|object typed variable - New regression test in tests/PHPStan/Analyser/nsrt/bug-14319.php - New benchmark test in tests/bench/data/bug-14319.php
Instead of counting all union type members, only count union members that contain HasOffsetValueType accessories. This more precisely targets the source of exponential growth while avoiding false positives on unions that are large for other reasons. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
staabm
force-pushed
the
create-pull-request/patch-cltr70w
branch
from
0cda4c2 to
87f29af
Compare
src/Analyser/MutatingScope.php
Outdated
| $exprVarType = $scope->getType($expr->var); | ||
| $isArray = $exprVarType->isArray(); | ||
| if (!$exprVarType instanceof MixedType && !$isArray->no()) { | ||
| $tooComplex = false; |
Contributor
There was a problem hiding this comment.
The var name si too vague.
Collaborator
Author
There was a problem hiding this comment.
Done. Renamed $tooComplex to $tooManyHasOffsetValueTypes to better describe what the variable tracks — whether the union type has exceeded the limit of HasOffsetValueType accessory types. All tests pass (11602 tests) and static analysis reports no errors.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
staabm
approved these changes
Mar 18, 2026
Collaborator
Author
|
The branch is clean and up to date. The PR is approved with no outstanding change requests. There's nothing to address — all previous feedback has been implemented and the reviewer has approved the PR. |
VincentLanglet
approved these changes
Mar 18, 2026
Collaborator
Author
|
The review from VincentLanglet is an APPROVED review with no new comments or change requests. All previous feedback has already been addressed:
There's nothing new to address — the PR is approved and ready to merge. |
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
4 participants
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
PHPStan hangs or takes extremely long when analyzing code with multiple consecutive
if ($rows['key'])blocks where$rowshas typearray|object. The analysis time grows exponentially with the number of if-blocks (6 blocks → 12+ seconds, effectively hanging for real-world code with more blocks).Changes
ARRAY_DIM_FETCH_UNION_TYPE_LIMIT = 8constant tosrc/Analyser/MutatingScope.phpspecifyExpressionType(), when processingArrayDimFetchexpressions, skip propagatingHasOffsetValueTypeintersections andgeneralOffsetAccessibleTypeintersections to the parent variable when the parent type is already aUnionTypewith more than 8 memberstests/PHPStan/Analyser/nsrt/bug-14319.phpwith assertType checkstests/bench/data/bug-14319.phpfor performance regression trackingRoot cause
When processing
if ($rows['key'])where$rowsisarray|object,specifyExpressionTypenarrows the parent variable$rowsby intersecting it withgeneralOffsetAccessibleType(convertingobjecttoArrayAccess) andHasOffsetValueType('key', <truthy/falsy type>). This creates an intersection type for each union member.After merging the truthy and falsy branches of each if-block, the type of
$rowsbecomes a union of both branch types, doubling the number of union members. With N consecutive if-blocks checking different keys, the type grows to O(2^N) union members. Each subsequentTypeCombinator::intersectcall on this growing union becomes exponentially slower.The fix introduces a complexity limit: when the parent variable's type already has more than 8 union members, the narrowing propagation to the parent is skipped. The dim fetch expression itself (
$rows['key']) is still narrowed correctly, so analysis precision is maintained for the accessed value. Performance improves from 12+ seconds to ~1 second for the reproduction case.Test
The regression test
bug-14319.phpreproduces the exact scenario from the issue: a function returningarray|object, followed by 6 consecutiveif ($rows['key'])blocks with.=concatenation. It includesassertTypechecks to verify that type inference still works correctly (variable types are properly inferred asstringafter the operations).Fixes phpstan/phpstan#14319