microsoft
tsgo regression: TS2590: Expression produces a union type that is too complex to represent.
Reproduction: https://github.com/andreww2012/tsgo-regression-ts2590 (running tsgo in Stackblitz environment doesn't work, it results in the "<...>/node_modules/@typescript/native-preview-linux-x64/lib/tsgo: line 1: a command can only contain words and redirects" error.
Another type ordering issue. When inferring type arguments for the call Object.entries(rules), the checker needs to perform subtype reduction on the following large union type with 1371 constituents:
"\"error\" | \"off\" | \"warn\" | 0 | 1 | 2 | [RuleSeverity] | [RuleSeverity, (_FuncNamesValue | undefined)?] | [RuleSeverity, ({ ArrayExpression?: _StylisticArrayElementNewlineBasicConfig | undefined; ArrayPattern?: _StylisticArrayElementNewlineBasicConfig | undefined; } | _StylisticArrayElementNewlineBasicConfig | undefi...
Since this involves a very large number of type relationship checks (it's basically an N^2 problem), after 100,000 checks we estimate the remaining amount of work. Due to type ordering differences in union types, the estimate comes out to just below 1M in the old compiler and just above 1M in the new compiler. Once the estimate is >1M remaining operations, we decide to report an error.
The size of the union type is basically a function of the number of properties in the eslint RuleOptions interface. It wouldn't take that many more rules to cause the old compiler to also issue the complexity error.
@ahejlsberg we are also experiencing this in a proprietary codebase. Can you share how to generate these estimate values?
the estimate comes out to just below 1M in the old compiler and just above 1M in the new compiler
I'd like to run this against a type in our own codebase and see the difference between tsc and tsgo.
