TypeScript: TS v2.3.1 runs out of memory compiling FP library

TypeScript Version:: 2.3.1

Repo: https://github.com/gcanti/fp-ts

After upgrading typescript from 2.2.2 to 2.3.1 the compilation (npm run build) fails with the following error:

<--- Last few GCs --->

   25725 ms: Scavenge 1407.7 (1457.4) -> 1407.7 (1457.4) MB, 46.2 / 0 ms (+ 24.7 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
   27079 ms: Mark-sweep 1407.7 (1457.4) -> 1406.4 (1456.4) MB, 1354.1 / 0 ms (+ 1071.3 ms in 617 steps since start of marking, biggest step 25.4 ms) [last resort gc].
   28376 ms: Mark-sweep 1406.4 (1456.4) -> 1405.9 (1457.4) MB, 1297.0 / 0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x1985f0ce3ac1 <JS Object>
    1: recursiveTypeRelatedTo(aka recursiveTypeRelatedTo) [/Users/giulio/.nvm/versions/node/v5.5.0/lib/node_modules/typescript/lib/tsc.js:~27814] [pc=0xf9f8ea8a65b] (this=0x1985f0c04189 <undefined>,source=0x173e2ea53611 <a Type with map 0x1089a6556cc9>,target=0x95cb168fbb1 <a Type with map 0x1089a6556b69>,reportErrors=0x1985f0c04299 <false>)
    2: isRelatedTo(aka isRelatedTo) [/Users/giulio/.n...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6

Somehow seems related to the modules Tuple.ts and Apply.ts

In the module Tuple.ts if I comment the following lines

declare module './HKT' {
  // interface HKT<A> {
  //   Tuple: Tuple<any, A>
  // }
  interface HKT2<A, B> {
    Tuple: Tuple<A, B>
  }
}

the compilation doesn’t crash.

Alternatively if I don’t touch Tuples.ts but I comment out all the liftA* functions in Apply.ts the compilation doesn’t crash.

Expected behavior: Compilation success

Actual behavior: Compilation fail

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 3
  • Comments: 28 (19 by maintainers)

Most upvoted comments

fp-ts is now part of our RWC corpus so we should notice any performance regressions in the future.

Update from talking to @ahejlsberg. The inference-too-deep cap should maybe be removed entirely — it was a mistake from when we believed that inference should behave similarly to assignability checking.

@ahejlsberg is working on a fix that just quits when inference sees an instantiation of a type that it has seen before. That should fix this bug.

I’ll also add fp-ts to our real-world code test suite after the bug is fixed so that we can catch compiler bugs in this library and similar FP/monad libraries.

@sandersn It took me ages to reduce the test case down to something I could share, but I want to help 😃. This is as simple as I could get it whilst retaining the memory issue:

https://github.com/OliverJAsh/ts-2.4-memory-issue

Hope that helps!