Omit producing "JavaScript heap out of memory" with v3.3

TypeScript Version: 3.4.0-dev.201xxxxx

• 3.3.0-rc
• 3.3.3333
• 3.4.0-dev.20190223

Search Terms: Omit

Code

// using "@types/react": "^16.8.4"

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

type XXX = Omit<React.HTMLAttributes<HTMLElement>, 'title'>;  // <= this alias is not working

Expected behavior: It should work as early versions, last tested v3.2.4

Actual behavior: Compiler throws “JavaScript heap out of memory” and same happens with VSCode Intellisense (stuck for minutes without proper answer).

Playground Link:

Tested code working with playground 3.3. (pasting @types/react at bottom), too big to share.

Related Issues:

[AnyhowStep]

Just curious.

If you run node --max-old-space-size=8192 ./node_modules/typescript/lib/tsc.js --diagnostics, do you still get OOM?

If it does complete, what does it say for Memory used? For example, for one of my projects, my output says Memory used: 1310899K. So, 1.3GB

[weswigham]

Yep, this looks like a carbon copy of how #29949 works - the Tag of type keyof JSX.IntrinsicElements is a union of 110 items - to check all 110 of the possible tags, we union those signatures - meaning we intersect the arguments. We then intersect 110 ref types (which are all undefined | null | string | RefFunc<T> | RefObj<T>) which becomes crazy costly with how we construct intersections, as it happens. What’s worse is that since there’s both the func and object types, they combine in strange and interesting ways - like, say we only were looking at a "input" or a "button" - well, that could have a ref that is a function which tags a "button" ref param, but is also an object which takes an "input" ref property. Or vice versa. Or both as params, or both as objects. From 2 effective inputs, we get a union of 4 output types - and this multiplication occurs for every element of the union. Running the numbers, the resulting union is supposed to have… 10^33 members or so?

@ahejlsberg what do you think we should do for a intersection/union nesting where flattening the nesting would produce an absurd number of types? There’s a strong desire to check this pattern correctly, so I don’t think some kind of resource limit would work here; but at the same time, optimizing construction won’t cut it here - the sheer number of types scheduled to be produced by this flattening operation is huge (and since there’s a pair of object types, it doesn’t simplify nicely at all).