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)
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!