Constant-scalar and enum-case union fast path in TypeCombinator::intersect

[SanderMuller]

Problem

TypeCombinator::intersect() implements A & (B | C) by distributing the members of one union across the other and rebuilding the result with union(). For two unions of width n and m that is O(n*m).

This becomes pathological when a variable is assigned across many === narrowing branches:

function f(int $x): string {
    $v = 0;
    if ($x === 0) $v = "0";
    if ($x === 1) $v = "1";
    // ... one branch per constant ...
    return (string) $v;
}

The conditional-expression machinery repeatedly intersects $v's growing constant-value union with the narrowed consequence union (also a growing constant-value union), so intersect runs O(n) times on width-O(n) operands and analysis grows super-linearly. Reported as phpstan/phpstan#14869.

Fix

When both operands are plain unions whose members are all disjoint constant scalars, the intersection is just their value-keyed set intersection, computable in O(n). The fast path is restricted to the exact UnionType class so BenevolentUnionType and the template union types keep their dedicated handling, and it excludes class-string constant strings (the class-string flag is not captured by the value) and floats (-0.0 / NAN comparison quirks). Anything outside that set falls back to the existing distribution, so behaviour is unchanged.

Numbers

Single file, level 8, single process, result cache cold (hyperfine, N = number of branches):

N	before	after
100	0.79s	0.52s
200	3.07s	0.78s
400	21.27s ± 0.04	2.48s ± 0.01

That is 8.6x at N=400; the intersect call count on that case drops from ~21M to linear.

Tests

New dataIntersect cases in TypeCombinatorTest covering constant-int, constant-string and mixed-with-null overlaps, the empty (never) result, a single-member result, and a bail back to the general path. TypeCombinatorTest, UnionTypeTest and NodeScopeResolverTest are green, and make phpstan and the coding standard are clean.

This is independent of #5857 (it does not touch TypeCombinator), so it helps both current 2.2.x and the single-pass work once that lands.

Update (review feedback)

Extended the fast path to enum-case unions and mixed constant-scalar + enum-case unions, keyed by class + case name (the identity EnumCaseObjectType::equals() uses). The same blowup with enum cases (a variable assigned enum cases across N === branches over an N-case enum) ran ~30s at N=400 before, ~3.8s after. Backed enum cases are keyed as cases, not by their backing scalar. Added TypeCombinatorTest cases for enum-only, mixed, backed-enum-vs-int, and constant-string-vs-int; NodeScopeResolverTest green.

[SanderMuller]

Related: #5934 also speeds up TypeCombinator from this reproducer, but at a different layer (it makes the post-distribution usort conditional). This PR returns before the distribution for constant-scalar unions, so the two do not overlap and merge cleanly together (verified locally, TypeCombinatorTest green). Complementary, not competing.

[ondrejmirtes]

Please try to apply this to a union of enum cases as well. And potentially to unions that have both constant scalars + enum cases.

But first try to reproduce the same pathological case, should be slow before the optimization.

[SanderMuller]

Done, and I reproduced it first as you suggested.

Reproduction: the same shape with enum cases (a variable assigned enum cases across N === branches over an N-case enum) hits the same intersect() distribution, about 30s at N=400 before the optimization.

The fast path now keys enum-case members by class + case name, so it covers pure enum-case unions and mixed constant-scalar + enum-case unions. Same reproducer: about 30s to 3.8s at N=400, and the mixed int|enum shape drops similarly.

One note in case it is useful: I first keyed enum cases by describe(VerbosityLevel::cache()) the way union() does, but that folds in a subtracted type that EnumCaseObjectType::equals() ignores, so a narrowed Enum::Case and a bare one got different keys and the intersection came out as never. NodeScopeResolverTest caught it on the in_array/enum narrowing cases. Keying by class + case name fixes it and matches what equals() compares. Backed enum cases are keyed as cases, not by their backing scalar, so TestEnum::TWO (= 2) is not confused with the integer 2.

New TypeCombinatorTest cases cover enum-only unions, mixed scalar + enum, the backed-enum-vs-int distinction, and constant-string-vs-int. TypeCombinatorTest and NodeScopeResolverTest are green.

[ondrejmirtes]

A failure in the test suite. I'm fine with updating the error message expectation tbh.

[SanderMuller]

Thanks. I looked into that failure and it turned out not to be cosmetic: the fast path was collapsing a refined enum-case type. getEnumCaseObject() returns the case not just for a bare enum case but also for a refined member like $this(Foo)&Foo::BAR (and whole single-case enums, and enums subtracted to one case), so keying those by class + case name dropped the refinement and the match arm's type changed.

I guarded the enum branch with EnumCaseObjectType::equals(): a bare case equals its own getEnumCaseObject(), a refined member does not (equals() requires an EnumCaseObjectType), so refined members fall back to the slow path and keep their form. MatchExpressionRuleTest::testLastCondition now passes unchanged, so no expectation update is needed. I also applied @staabm's note to skip building the second member map when the first already bails.

Sorry for the red: I had validated on a subset and missed the Rules-layer test, so I ran the full suite this time. It is green now (the one local failure I see is an unrelated, pre-existing signature-map test that also fails on the base, a dev-PHP-build artifact).

[ondrejmirtes]

One more thing - please put a code sample which was slow and is fast now into tests/bench/data with a unique namespace. No more is required, I'll push a regenerated phpbench baseline once this is merged.

[SanderMuller]

One more thing - please put a code sample which was slow and is fast now into tests/bench/data with a unique namespace. No more is required, I'll push a regenerated phpbench baseline once this is merged.

Added one for the scalar and one for the enum case, can you review them?

[ondrejmirtes]

Thank you!