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

[artola]

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]

I can't seem to repro this on 3.3.333 or on @next (tried typescript@3.4.0-dev.20190227 and 3.4.0-dev.20190223). Is there more here, like certain compiler settings or additional installed @types packages (beyond @types/react and csstype), that are required to trigger this?

[artola]

@weswigham Thanks a lot for the prompt reply. I have debugged this issue to discover that my initial thought regarding Omit as culprit was wrong, the OOM is due some other issue. I managed to create a repro with a minimum case that fails and 2 cases where partially works, to be considered that same code was properly compiling up to 3.1.16. Repro and detailed info here: https://github.com/artola/ts-bug

Produces OOM during compilation:

import React, {PureComponent} from 'react';

interface TextProps {
  tag: keyof JSX.IntrinsicElements;
}

export class Text extends PureComponent<TextProps> {
  render() {
    const {
      tag: Tag,
      children
    } = this.props;

    return (
      <Tag ref={()=>{/* oops */}}>
        {children}
      </Tag>
    );
  }
}

[weswigham]

Oho? Maybe related to #29949 then.

[artola]

@weswigham Looking at #29949 and even disabling strict or just strictFunctionTypes it is failing.
Might be related with large unions? I would say yes, but I do not see why/how in the example above.

[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).