RangeError: Maximum call stack size exceeded in TS 2.1.4 #12735
Comments
|
we would need to look at the code that triggered this exception to be able to diagnose the issue. can you share the sources? |
mhegazy
added
Bug
|
mm.. does nto seem to reproduce on my box.. c:\test\12735\WebCeph>webpack --bail --progress
Hash: 9f18cc72158839fd04f5
Version: webpack 2.1.0-beta.27
Time: 20127ms
Asset Size Chunks Chunk Names
4502ba795be584933131c195c7a53052.png 279 bytes [emitted]
800608933790f1502ddb5dc9ba746f62.png 1.24 kB [emitted]
bundle_9f18cc72158839fd04f5.js 2.25 MB 0 [emitted] bundle
lib_9f18cc72158839fd04f5.js 764 bytes 1 [emitted] lib
common_9f18cc72158839fd04f5.js 1.39 MB 2 [emitted] common
index.html 578 bytes [emitted]
sw.js 206 kB [emitted]
[1084] ./src/analyses nonrecursive .ts$/ 275 bytes {0} [built]
[1087] multi bundle 28 bytes {0} [built]
[1088] multi lib 316 bytes {1} [built]
+ 1086 hidden modules
Child serviceworker-plugin:
+ 6 hidden modules
|
|
Did you upgrade to 2.1? I've had the same issue on 2 machines (both running Linux) since the nightlies with node 7.2, 6.9 and 4.7. |
|
I have the same problem here, I'm porting a project to TS and I was getting a bunch compiler errors with 2.0.10, after updating to 2.1.4 tsc crashes. |
|
@forabi any chance you are using |
|
I got it to repro. I'm on Linux too, although the stack trace doesn't seem particularly Linux-influenced. |
|
Also fails for |
|
@maghis No. Here is my {
"compilerOptions": {
"target": "es2015",
"lib": [
"es5",
"es2015",
"webworker",
"dom"
],
"outDir": "build/",
"allowJs": true,
"allowSyntheticDefaultImports": true,
"noImplicitAny": true,
"moduleResolution": "node",
"jsx": "react",
"sourceMap": true,
"module": "commonjs",
"isolatedModules": true,
"forceConsistentCasingInFileNames": true,
"preserveConstEnums": true,
"traceResolution": false,
"noImplicitReturns": true,
"pretty": true,
"noUnusedParameters": true,
"strictNullChecks": true,
"noUnusedLocals": true,
"noImplicitThis": true,
"skipLibCheck": true,
"skipDefaultLibCheck": true,
"baseUrl": ".",
"paths": {
"*": [
"*",
"src/*"
]
}
},
"compileOnSave": true,
"exclude": [
"node_modules",
"src/**/*.test.ts",
"build/**"
]
} |
|
Looks like the culprit is of the form let acc: T[] = [];
for (const x of o1.xs) {
acc = [...acc, a, ...o2.xs, ...f(o2), ...flatten(map(o2.xs, g)]
}I anonymised the code since it's a private repo. It's I'll try to reduce the repro down to something the size of that snippet. I don't know why |
|
@sandersn Thanks for taking the time to investigate the issue :) The code does not seem so elegant but it used to compile with 2.0. Can I do something to help? Is it a Linux-specific issue? Can someone reproduce on a Mac? |
|
I have the failing snippet pretty small, but I haven't got it to repro outside your project yet. I doubt that it is Linux-specific, although I think it is specific to your set of compiler options. Here's what I have so far: type Fake = { components: any };
export const getNestedComponents = (fake: Fake): Fake[] => {
let additional: Fake[] = [];
for (const subcomponent of fake.components) {
console.log(subcomponent);
additional = [
...additional,
];
}
return additional;
}Obviously, It passes when I take out the loop, so I'm pretty sure it's a bug in control-flow analysis that triggers with some combination of the compiler options. I think I touched array spread control flow when adding object spread, so that's probably where the bug is. But it might be in the expanding array types code, which is new as well, and relies heavily on control-flow analysis. |
|
I found a fix and an even smaller repro, but still no isolated test. If, in Here's the smaller repro. I stuck it in let additional = [];
for (const subcomponent of []) {
additional = [...additional];
} |
|
It turns out the above program crashes with // @noImplicitAny: true
let additional: number[] = [];
for (const subcomponent of []) {
additional = [...additional];
}I'm debugging right now to find out why. |
|
@sandersn it's not 2.1.4 specific, in my project I can reproduce it with 2.0.10 too, by switching |
|
@sandersn I'm trying to repro, it's probably a coincidence, I had never seen it before. |
|
The reason that webpack crashes both with and without the type annotation is that, when called from webpack, the global symbol table is empty, so no array types can be created as the checker starts. This creates a bunch of errors, but those are also not reported with this webpack configuration. And without being able to check array types, the compiler just treats everything like an evolving array type, even if it has an annotation. Then it hits this bug. |
|
Fix is up at #12808 |
|
Nope, the magic ingredient was loop + spread expression + no implicit any + evolving array types, and I don't need the original now that I know that. There is still a (separate) bug in the way webpack invokes the compiler , so you might still want to play with your webpack configuration to see if you can get it to show you compile errors. |
|
@sandersn Yeah, |
|
Well, |
TypeScript Version: 2.1.4
The project used to compile without any issues on TS 2.0, but it fails after upgrading to TS 2.1.4 without changing any code. I would be happy to give access to the repo if it would help.
Expected behavior:
The code compiles without issues
Actual behavior:
RangeError: Maximum call stack size exceeded
The text was updated successfully, but these errors were encountered: