[ty] Narrow later match cases after always-true guards

[AlexWaygood]

Summary

ty currently retains values matched by an earlier match case whenever that case has a guard, even if the guard is statically true. This can make later pattern captures too broad and leave impossible cases appearing reachable.

This PR changes our inference so that we treat a pattern whose guard is statically true like an unguarded pattern when narrowing later cases, including enum-pattern reachability. False and ambiguous guards remain conservative. Guard truthiness uses the existing condition analysis, including its conservative recovery for inference cycles.

On its own, this isn't a particularly important change, but codex was worried that analyzing reachability of match patterns without this change would lead to false positives/negatives when it came to adding a check that would complain about non-exhaustive match statements. I'm therefore separating this into a standalone change that can be merged first.

A naive implementation of this PR led to hangs (and eventual panics, if the script was left for a very long time) on three py-fuzzer seeds. Some changes were therefore required to reachability.rs to tweak which queries we cache and which we don't. Happily, this PR appears to have the side effect of significantly speeding up one of our microbenchmarks following those tweaks.

[astral-sh-bot]

Typing conformance results

No changes detected ✅

Current numbers

The percentage of diagnostics emitted that were expected errors held steady at 98.24%. The percentage of expected errors that received a diagnostic held steady at 98.24%. The number of fully passing files held steady at 134/146.

[astral-sh-bot]

Memory usage report

Memory usage unchanged ✅

[astral-sh-bot]

ecosystem-analyzer results

No diagnostic changes detected ✅

Flaky changes detected. This PR summary excludes flaky changes; see the HTML report for details.

Full report with detailed diff (timing results)

[codspeed]

Merging this PR will improve performance by 8.63%

⚡ 1 improved benchmark
✅ 161 untouched benchmarks
⏩ 60 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	ty_micro[large_union_narrowing]	517 ms	475.9 ms	+8.63%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing alex/always-true-match-guards (6f12c13) with main (00dda0e)}

Footnotes

1. 60 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[sharkdp]

Thank you. This makes a lot of sense to me.

After reading the PR description I was expecting to see a test case like the following, but that seems too ambitious. Probably requires additional changes to narrowing?

class Color(Enum):
    RED = 0
    BLUE = 1

class Answer(Enum):
    NO = 0
    YES = 1

def _(color: Color, answer: Answer):
    match color:
        case Color.RED if answer is Answer.NO:
            x = 0
        case Color.RED if answer is Answer.YES:  # always true guard
            x = 1
        case Color.RED:
            x = 2  # unreachable
        case _:
            x = 3

    reveal_type(x)  # Literal[0, 1, 2, 3] on your branch, excluding 2 would be nice

[sharkdp]

Deeply disappointed that you didn't pick up my

class Answer(Enum):
    NO = 0
    YES = 1

pattern.

[AlexWaygood]

After reading the PR description I was expecting to see a test case like the following, but that seems too ambitious. Probably requires additional changes to narrowing?

That would be very cool indeed, but yes, I think it's too ambitious for now