bug in compiler causing it to get 100% cpu and never ends!

[nisimjoseph]

TypeScript Version: nightly (2.0.0-dev.20160903)
The compiler continues on 100% CPU and never end the operation.
this is caused by using very long IF statement like the one exists in Device Detection in the following file URL:
https://github.com/hgoebl/mobile-detect.js/blob/master/mobile-detect.js

you have here a long if, in the "mobileGrade" function, this IF statement stuck the compiler when you take that JS file and use "allowJs" compiler option.
in addition, when it ported that file to TS and kept all content as is, just changed some things, it stuck as well.
after cutting the file in different areas I found it that IF causing ​hat issue. no matter what IFs parts you cut, it just passes a number if IF parts and stuck.

Code
https://github.com/hgoebl/mobile-detect.js/blob/master/mobile-detect.js
with allowJs compiler.

// A *self-contained* demonstration of the problem follows...

Expected behavior:
finish the compilation with/without errors
Actual behavior:
just stuck on 100% CPU and never ends.

[vladima]

can be reproduced without allowJs, gist with an extracted snipped that demonstrates the problem: https://gist.github.com/vladima/86e528ee00cf64c8d3132fef57252a07

[vladima]

at glance it seems that culprit is the narrowTypeByTypePredicate since i.e. in order to get resolved signature of t.os('iOS') we need to get the type of t which in turn requires to do more narrowing. Effectively then deeper we do the right hand side of complicated binary expression in the condition of if statement then more repeated nested calls do narrowTypeByTypePredicate we do which quickly turns exponential. As a test I've converted type predicate like calls into logical expressions (effectively replacing t.os('iOS') with ts.os('iOS') === true) - with this change in original .js file it can be compiled in ~1.5s.

[vladima]

also with naive cache in narrowTypeByTypePredicate using key below unchanged orignal .js file can be compiled in ~1.6s

const key = `${getNodeId(reference)}|${declaredType.id}|${assumeInitialized}|${flowContainer ? getNodeId(flowContainer) : 0}|${getNodeId(callExpression)}|${type.id}|${assumeTrue}`;

// CC: @ahejlsberg

[ahejlsberg]

Fix available in #10703.

[ahejlsberg]

@nisimjoseph Fix will be in the next nightly build.

[nisimjoseph]

wonderful!

[mhegazy]

Ported to release-2.0 in #10726