Augment BooleanAnd falsey and BooleanOr truthy type narrowing when left and right conditions narrow different expression keys

[phpstan-bot]

Summary

When isset($test['hi']) && is_string($test['hi']) was used in a combined && condition with an early return, PHPStan failed to narrow the array union type in the falsey branch. Splitting the condition into nested if blocks worked correctly. The fix recovers the lost type narrowing for both BooleanAnd falsey and the De Morgan dual BooleanOr truthy.

Changes

• Added augmentDisjunctionTypes() method to src/Analyser/TypeSpecifier.php that computes both disjunction-path filtered scopes and checks if candidate expressions are narrowed in both paths. If so, it creates a sureType with the union of the narrowed types.
• Called this method in the BooleanAnd falsey branch (after the existing intersectWith) using left-falsey and right-falsey-given-left-truthy scopes.
• Called this method in the BooleanOr truthy branch (after the existing intersectWith and augmentBooleanOrTruthyWithConditionalHolders) using left-truthy and right-truthy-given-left-falsey scopes.
• Updated tests/PHPStan/Analyser/data/type-specifying-extensions-2-false.php and type-specifying-extensions-2-null.php: $foo is now correctly string instead of string|null because the test extension fires in all contexts and both disjunction paths narrow it.
• Updated tests/PHPStan/Rules/Classes/ImpossibleInstanceOfRuleTest.php (testBug3632): after progressive elimination by early returns, $a is now correctly narrowed to null and $b to NiceClass, producing an additional true-positive instanceof error at line 36.
• Updated tests/PHPStan/Rules/Comparison/BooleanNotConstantConditionRuleTest.php (testBug11903): PHPDoc tip removed from line 21's error because the narrowing is now from control flow rather than PHPDoc types.

Root cause

In TypeSpecifier::specifyTypesInCondition, the falsey branch of BooleanAnd (and truthy branch of BooleanOr) uses SpecifiedTypes::intersectWith() to combine type assertions from the two operands. intersectWith only keeps expression keys present in both operand sets. When the left condition narrows $test (the array variable) and the right condition narrows $test['hi'] (an array offset), they have different expression keys, so intersectWith drops both — resulting in no narrowing at all.

The fix adds a post-intersection augmentation step that computes the two actual filtered scopes (one for each disjunction path) and checks if both paths narrow the same expression. If so, the union of the narrowed types is added as a sureType.

Analogous cases probed

• BooleanOr truthy (De Morgan dual): same information loss pattern, fixed with the same augmentDisjunctionTypes method using truthy scopes instead of falsey scopes. Test added.
• Other type-check functions: is_array, is_int, is_float, is_bool all tested in combination with isset — all pass with the fix.
• array_key_exists: tested as an alternative to isset — passes.
• Conditional expression holders path (via augmentBooleanOrTruthyWithConditionalHolders): already existed for BooleanOr truthy but only handles candidates from pre-existing conditional holders in the scope, not from the current condition's sureTypes. The new augmentation complements it.

Test

• tests/PHPStan/Analyser/nsrt/bug-14566.php: regression test for the reported bug with isset && is_string on array{}|array{hi: 'hello'}|array{hi: array{0: 42, 1?: 42}}, plus:
  • Nested-if baseline (already worked)
  • Combined && with early return (the reported bug)
  • Combined && with offset assignment (from the issue's playground)
  • || dual case (!isset || !is_string)
  • is_array, is_int, is_float, is_bool variants
  • array_key_exists variant

Fixes phpstan/phpstan#14566
Fixes phpstan/phpstan#13061
Fixes phpstan/phpstan#7259

[VincentLanglet]

To me the integration test errors are correct

[ondrejmirtes]

Please look at issue-bot results and decide whether anything else is fixed too

[VincentLanglet]

Add non regression for phpstan/phpstan#13061
(with the code snippet https://phpstan.org/r/923d55d8-296e-42ea-897b-0dffb23e4ef5)

Add non regression for phpstan/phpstan#7259
(with both the code snippet https://phpstan.org/r/dca4f949-ab14-41d0-b02d-09adc7ff011e and https://phpstan.org/r/ee55e085-aff1-4c4e-9ef6-96ceceec9e83)

[phpstan-bot]

Pushed. Added two regression test files:

• tests/PHPStan/Analyser/nsrt/bug-13061.php — tests that isset($scenarioHash['type']) && $scenarioHash['type'] === 'outline' correctly narrows out the TOutlineHash type in the else branch, so loadScenarioHash() receives only TScenarioHash.
• tests/PHPStan/Analyser/nsrt/bug-7259.php — tests both the nullable DateTimeImmutable variant and the string|int variant where || at the outer level with nested && conditions and assignments guarantees both variables are non-null / string by the time they're used.

Both make tests (12,038 tests) and make phpstan pass with no errors.

[ondrejmirtes]

I just want to see if it's slow and if it is, make the bot optimize it, then I'd merge it.

[VincentLanglet]

I just want to see if it's slow and if it is, make the bot optimize it, then I'd merge it.

Maybe you can help me on this @staabm ?

• I don't really understand the benchmark test result
• I never measured perf on phpstan project. I assume you could run test with and without this fix with your usual tools ?

[ondrejmirtes]

there's a lot of files these changes make slower, as the phpbench workflow run shows: https://github.com/phpstan/phpstan-src/actions/runs/25682660203/job/75398052005?pr=5595

Looks like all of them, or at least some of them are related to BooleanAnd and BooleanOr which tracks.

Please try to optimize these cases so they run as fast as on base 2.1.x branch, while still making the regression tests added in this PR work.

[phpstan-bot]

Pushed. The optimization defers the expensive filterByFalseyValue/filterByTruthyValue scope computations inside augmentDisjunctionTypes until after we've verified there are actual candidates worth checking.

The key insight: intersectWith drops expression keys only when the left and right sides of &&/|| narrow different expression keys. In the common case (both sides narrow the same expressions), all candidates are already in the intersection result, viableCandidates is empty, and we return immediately — no filtered scopes computed. This also eliminates the duplicate scope computation that was happening for BooleanOr truthy (where augmentBooleanOrTruthyWithConditionalHolders already computes the same truthy scopes).

[ondrejmirtes]

All of these files are still slow:

https://github.com/phpstan/phpstan-src/actions/runs/25692504674/job/75432317706?pr=5595

See:

17 variants failed:

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-5081.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-7581.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-7903.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-8146b.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-8215.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-9690.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-10538.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-10772.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-10979.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-11263.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-11913.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-12159.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-12800.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-13352.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-14207.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # bug-14590.php

  ✘ \PHPStan\Benchmark\RegressionBench::benchRunAnalyse # wordpress-user.php

try to run them with hyperfine on 2.1.x and then on this branch, you'll see the slowdown. Copy them outside of tests/bench/data if needed.

[phpstan-bot]

Pushed. Here's a summary of what I did:

The optimization adds three layers to augmentDisjunctionTypes that make it zero-cost for the common case:

1. Count-based fast path (O(1)): If intersectWith preserved all expression keys from both sides, return immediately. This handles $x > 0 && $x < 10 patterns where both sides narrow the same variables.

2. Lazy left scope: Only compute filterByFalseyValue(leftExpr) first — always cheap since leftExpr is a simple expression in recursive &&/|| processing.

3. Lazy right scope: Only compute the expensive rightScope.filterByFalseyValue(rightExpr) when at least one candidate passes the left narrowing check. For long && chains like bug-12800.php (41 comparisons of different expressions), the left check fails for all candidates because a simple comparison being false doesn't narrow unrelated expressions. This avoids the O(n²) recursive processing of compound right expressions.

A/B benchmark results (same machine, augmentDisjunctionTypes enabled vs disabled):

• All 17 flagged files show <1% difference, confirming zero measurable overhead
• 13 of the 17 files have zero &&/|| operators — the CI failures for those files are purely due to the benchmark VM being slower than the baseline VM

[ondrejmirtes]

@staabm Please take over this and test if these files are experiencing real slowdown on your computer on 2.1.x vs. this branch.

[ondrejmirtes]

Sorry, one more try from me. I thought I pushed a baseline update yesterday but I did not.

[staabm]

I can only have a look in a few hours. feel free to play with it meanwhile.

[ondrejmirtes]

It's good now. I'll try to revert the latest fix to see if the benchmark is still ok.

[ondrejmirtes]

Alright, it's green, let's go