CALL_AND_RETRY_LAST Allocation failed on 3.5.0-rc

[JoshuaKGoldberg]

TypeScript Version: 3.5.0-rc

Search Terms: CALL_AND_RETRY_LAST Allocation failed 3.5.0-rc

Code

This is a private code base so I'll send an email to Daniel Rosenwasser with a zip.

It contains roughly 600 JavaScript files and 150 TypeScript files (we're mid-conversion!).

Expected behavior:

Compiles correctly, as it did in 3.4.2

Actual behavior:

yarn run v1.15.2
$ tsc

<--- Last few GCs --->

[146:0x288cec0]   194648 ms: Mark-sweep 1371.8 (1450.0) -> 1371.8 (1450.0) MB, 899.4 / 0.0 ms  allocation failure GC in old space requested
[146:0x288cec0]   195547 ms: Mark-sweep 1371.8 (1450.0) -> 1371.8 (1410.5) MB, 898.9 / 0.0 ms  last resort GC in old space requested
[146:0x288cec0]   196415 ms: Mark-sweep 1371.8 (1410.5) -> 1371.8 (1410.5) MB, 868.2 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x12ae99a57c1 <JSObject>
    1: set(this=0x3f5e79846d91 <Map map = 0x37e9c78848d9>,0x1fc46c124e61 <String[47]: 6,78748,78757,78774,8,78793,78818,7,78838,78852>,0x1fc46c124e89 <Type map = 0x27f5ecd0eee1>)
    2: getIntersectionType(aka getIntersectionType) [/root/project/node_modules/typescript/lib/tsc.js:~33449] [pc=0x3548967bf825](this=0xa86fe2022d1 <undefined>,types=0x1fc46c124a99 <JSArray[10]>,aliasSymbol=0xa86fe2022d...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 2: 0x11e73ec [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 6: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate(v8::internal::Isolate*, int, v8::internal::PretenureFlag) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 7: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash(v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 8: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::EnsureGrowable(v8::internal::Handle<v8::internal::OrderedHashMap>) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
 9: v8::internal::Runtime_MapGrow(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/nvm/versions/node/v8.10.0/bin/node]
10: 0x354895e842fd
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Exited with code 134

Related Issues: #16834

[weswigham]

I think your example's maybe similar to #30050. Minimally, I can confirm that the work we're spending all our time doing before we OOM is intersection construction. #31476 is not sufficient to fix the underlying issue there (which from #30050 is, simply put, 2^len(keyof React.ReactHTML) combinations of possible ref types is wholly unreasonable). I can also at least confirm that deleting @types/react gets your project back into a state where it finishes a build, as does simply reducing the number of elements in the ReactHTML interface in the react declaration file.

[weswigham]

Yeah, it's ultimately the same - your content container is a HOC which takes a keyof ReactHTML, and checking the props on that component is huuuuuuuuugely expensive (since it's really a union of over 100 components). Checking 100 calls usually wouldn't be that bad; but our intersection/union normalization process expands the types for things like the ref member or the onChange handler when we compare them memberwise, resulting in us attempting to create unions with more members than we can possibly fit in memory. 😄

Specifically, we probably end up making this type when we try to get the contextual type for a prop for the ref example - in your example, it happens when we go to attempt to see if we need to report excess property errors on the call. At least for your example, I think we might be able to do better by deferring when we build the types of union properties.

Patched and built locally with this PR.
Fwiw still get an OOM as per #30050.