[ty] Higher limit for number of non-recursive union literals

[Minibrams]

Summary

This changes the limit for the number of non-recursive union literals from 256 to 8192; the same limit we use for the number of non-recursive enums.

The motivation behind this is that the argument for having a high limit for enums - because huge enums are common in generated code - also holds for string literals. Specifically, some absurdly popular generated API clients rely on string literals for API routes, e.g.:

client.get('/users/{user_id}')(params={ 'user_id': 123 })  # <-- The string literal is used to infer the request/response types

For clients like this, ty cannot handle API specs with more than 256 routes, which isn't uncommon.

Test Plan

• Updated crates/ty_python_semantic/resources/mdtest/call/union.md to reflect the increased limit
• Ran cargo nextest run -p ty_python_semantic -- mdtest::call/union.md

[astral-sh-bot]

Typing conformance results

No changes detected ✅

Current numbers

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

[astral-sh-bot]

Memory usage report

Memory usage unchanged ✅

[astral-sh-bot]

ecosystem-analyzer results

No diagnostic changes detected ✅

Large timing changes:

Project	Old Time	New Time	Change
pandas-stubs	9.64s	14.47s	+50%

Full report with detailed diff (timing results)

[codspeed-hq]

Merging this PR will degrade performance by 97.28%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 2 regressed benchmarks
✅ 55 untouched benchmarks
⏩ 60 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	ty_micro[many_string_assignments]	83.4 ms	5,240.1 ms	-98.41%
❌	Memory	ty_micro[many_string_assignments]	16.8 MB	361.7 MB	-95.35%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing Minibrams:main (0616e40) with main (b81d55e)}

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. ↩

[Minibrams]

LOL, nevermind.

I can't tell if the performance regressions are indicative of "real" or practically relevant regressions, but 97% degradation is pretty gnarly