Compiling with strictNullChecks never* completes

[myitcv]

TypeScript Version:

Compiling with strictNullChecks and version 1.9.0-dev.20160429

{
  "compilerOptions": {
    "declaration": false,
    "jsx": "react",
    "module": "system",
    "newLine": "LF",
    "noEmitOnError": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noImplicitReturns": true,
    "noLib": true,
    "removeComments": false,
    "rootDir": ".",
    "sourceMap": true,
    "target": "es5"
  }
}

Code

~205K lines of TypeScript code, type definitions etc.

Expected behavior:

Compilation should complete is comparable time to compilation run without strictNullChecks:

Compilation without strictNullChecks: ~10secs

Actual behavior:

Compilation **with** strictNullChecks: 22 mins and counting...

* where "never" == 22 mins and counting

Please let me know what I can help provide to help diagnose what's going wrong here.

[myitcv]

I've updated the headline issue to include our broader tsconfig.json settings

[mhegazy]

looks like there is an infinite loop somewhere :)

can you share a sample project the exhibits the issue? also we would be happy to sign an NDA to get access to the original project.

[myitcv]

@mhegazy unfortunately we don't have a minimal repro, and we can't share the project in question.

Before we go down the NDA route - is there some sort of tooling you can provide for us to help diagnose the problem, then we send you the output?

[mhegazy]

The easiest way is to run it in node and capture the stack trace:

node --stack-trace-limit=100000 <path to your tsc.exe>\tsc.js <args>

you need the same arguments you use to build your project. you should find these in your MSBuild log, search for tsc.exe.

if that does not work for whatever reason the next best is to debug under node-inspector:

npm install -g node-inspector
node-inspector

node --debug-brk <path to your tsc.exe>\tsc.js

[mhegazy]

The easiest way is to run it in node and capture the stack trace:

just to clarify, if there is not an exception, e.g. StackOverflow, this is not going to be useful.

if that does not work for whatever reason the next best is to debug under node-inspector:

I would run under the debugger, let it run for a few minutes, then break and share the stack. let it run again, and do that one more time, i would expect the stacks to be similar.

[myitcv]

just to clarify

Thanks, yes this was clear to me.

I ran for a few minutes, and then a few times did the combination of next and then bt. Results can be seen here:

https://gist.github.com/myitcv/fc5af13e042159345a3226147c24e415

Looks like some similarity between a number of the stack traces. Hopefully that helps to track things down, else we can arrange a screen share session and do this interactively.

Also included tsc.js for the sake of completeness

[ahejlsberg]

I took a quick look at the sample traces. It's all inside the getFlowTypeOfReference function in the type checker, so it's definitely related to control flow type analysis. My guess is there's an infinite loop either because of a particular combination of control flows we're not handling right or because the control flow graphs weren't constructed correctly by the binder. However, it could also be that the compiler is actually making (slow) forward progress on a particular combination that has gone exponential in processing time. It's really hard to say without looking at the code and the ASTs that are causing the issue.

[ahejlsberg]

An idea that could bring us a little closer to a repro. Let it run for a minute or so, then break. Now set a breakpoint on line 18575 in tsc.js and run to that. Then evaluate the following two expressions in the immediate window:

ts.getSourceFileOfNode(expr)
ts.getLineAndCharacterOfPosition(ts.getSourceFileOfNode(expr), expr.pos)

The first will tell you which source file the compiler is stuck in, the next will tell you the line and column of the expression it is looking at. Maybe you can isolate a repro from that.

[myitcv]

Thanks @ahejlsberg - will report back.

[jeffreymorlan]

Here's a file that exhibits this behavior: https://raw.githubusercontent.com/dojo/dojox/1.11.1/charting/axis2d/Default.js (rename to .ts)

Compiles in less than 1 second without --strictNullChecks, at least several minutes with it. (EDIT: 15 minutes)

[vladima]

@jeffreymorlan thanks for the info, it was very helpful. I think I've found the cause of the problem, fix proposal PR #8458. @myitcv can you try to build compiler from the cacheVisitedFlowNodes branch to see if original issue is addressed

[myitcv]

@vladima - the cacheVisitedFlowNodes seems to solve things for me, thanks

[ahejlsberg]

@myitcv Fix should be in the next nightly build. Let us know how it does for you.

[myitcv]

@ahejlsberg works like a dream, thanks