Seriously broken compiler in 0.9.1

Topics: General
Aug 12, 2013 at 3:17 AM
Edited Aug 12, 2013 at 3:19 AM
First of all I'd just like to thank everyone who is working on TypeScript, because it really has made my life so much easier and it's a great thing we have.

So I'm sorry to have to say that the new compiler is really seriously broken, to the point of being unworkable. I have Visual Studio Pro 2012 on Windows 8 (with 32GB RAM), but the issue I have is that the compiler freaks out whenever it encounters an error in my code. For example if I had a simple typo in a class, when I try to compile (shift + f6) instead of getting an error about the typo, I will get literally hundreds of duplicate error messages which are absolutely nothing to do with the typo. For example here is what I have to put up with:

https://www.dropbox.com/s/44ib5212qhyl612/vsbugout.png

647 errors! And the "Project" is listing one of my FILES, not the project name at all, and even more the line numbers might as well have been generated at random for all the good they do.

Now if I scroll down far enough I may find the actual error buried away in that list. But it gets REALLY confused and starts erroring all over my codebase in utterly random places. Things like claiming that comparing a number with the length of an array is an invalid comparison. The error is "Cannot compare type number with type number". That's really handy guys.

Debugging for me has gone from a breeze with 0.8.4 to something of a nightmare, that is taking forever to scroll through a huge stack of meaningless rubbish just to find the actual error. What's more the 'red squiggly underline' that is supposed to just underline errors will now underline all kinds of random stuff. I've seen it underline a period character before an object property, I've even seen it underline blank space and new-lines - heck 10mins ago it underlined an ENTIRE class. Hovering over the class just said "duplicate identifier", which was utter tosh - it was perfectly fine.

So right now I'm stuck. I can't roll back to 0.8 because you guys have made 0.9.1 the default download on the web site which is why I had to upgrade - I was getting too many emails from people saying they had downloaded 0.9.1 but couldn't compile my framework. So I upgraded to support it, but it's been nothing but pain. Surely I can't be alone here?
Aug 12, 2013 at 4:00 AM
I've come to the conclusion that the errors are utterly bogus, and that the actual real error is simply this:

1>VSTSC : tsc.js(40622, 13) JavaScript runtime error : Unable to get property 'type' of undefined or null reference

Am I right in thinking this is the new IE JS VM doing it's thing? It appears that I can hit compile over and over, and sometimes (if the luck of the Gods are on my side) it will compile successfully, but most of the time it errors with the above. It's as if my project is too large for the compiler to cope with and by some fluke it will occasionally make it through. But most the time the JS parser is erroring before maybe the compiler has finished building the output file? Not sure if that's even how it works, but it would make sense given the inconsistent results I'm getting. There is no way on earth that a compiler should work sometimes and not others without changing code in between.

Right now I can't in all seriousness recommend anyone use TypeScript for any real project. I think it's time to re-evaluate dropping it entirely and returning my framework back to native JavaScript. I'd rather not do this, but this is beyond a joke really.
Aug 12, 2013 at 9:27 AM
I've seen this weird behavior also. I had upgraded fresh to 0.9.1.1 for evaluation.
It seems that an error in a module is bubbled in all modules that import it!
I use AMD.


Aug 12, 2013 at 12:18 PM
I've found a "solution" to my current troubles. I've got another PC, installed TypeScript 0.8.3 on it, pull from my repo, do a 'search and replace' on "boolean" back to "bool" and then compile it. From 0.8.3 I get meaningful errors that actually make sense. I can then fix them on my main PC.

It is batshit crazy that I should have to be doing this, but it solves my troubles for now.
Coordinator
Aug 12, 2013 at 3:42 PM
If you're seeing this:

1>VSTSC : tsc.js(40622, 13) JavaScript runtime error : Unable to get property 'type' of undefined or null reference

It sounds like the compiler is crashing on something in the code. I'm going to copy this over to a work item. If you have a file we can investigate, we could look into what's throwing the compiler off.
Coordinator
Aug 12, 2013 at 3:42 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 12, 2013 at 3:59 PM
Is there any way you could create a compiler that dumps out something when it crashes? Like a log of where it currently got to, a dumpfile, anything similar? Then I could send you that rather than my current solution (which is several hundred TS files).
Coordinator
Aug 19, 2013 at 10:42 PM
We might be able to add that functionality in the long term. In the short term, if you can, it might make sense to run the compiler via the debug of node or a browser and catch the issue that way. The repro is the key for us to investigate fixing, and you might also be able to get a stack trace, too.
Aug 20, 2013 at 10:48 AM
Note (probably obvious, but just in case;-): the 40622 in that message is a line number, so you can already see where the code breaks. You could try wrapping the last line (which starts the compiler) in tsc.js in a try {...} catch(e) {console.log(e.stack)}, if your JS engine supports e.stack (node does).

node-inspector is a great help, if you run tsc.js via node, as is instrumenting the tsc.js source (in a throw-away copy) to get more details on which compiled sources are involved.

You still need a test case to reproduce (and to know when the bug is fixed), but it will be easier to shrink the example when you've got an idea of what goes wrong.
Aug 20, 2013 at 10:54 AM
then again, just running tsc.js via node should print a stack trace, unless the error is caught somewhere (then adding e.stack to the output would help).
Aug 25, 2013 at 5:31 PM
I don't compile via node.js but I'm tempted to do so just to use the inspector as you suggest. I was aware the 40622 was a line number but sadly the output file isn't retained after the compiler dies, so I can't actually inspect it. I don't know where, or even if tsc keeps its work files somewhere when compiling? But as no final output file was created I couldn't ever inspect it to see how far it had got.
Aug 25, 2013 at 10:56 PM
If it is a compiler crash, the error message gives a line number in the compiler source (which also is a JS file, generated from TS), not in your sources.

If you can run the compiler in a debugger, or get a stack trace some other way, you can find a function in that trace which knows which of your sources the compiler is looking at when it crashes. You can then see the file name in the debugger, or console.log it by modifying the compiler source. That might, with some luck or patience, allow you to shrink your project sources into a tiny project consisting of just enough code to trigger the compiler crash. With that in hand, the TS team can reproduce the bug, and they will know when they have fixed the bug.

The TS team seems to be willing to look into larger codebases as well, if those reproduce a crash reliably. I'm just suggesting that if you can shrink the codebase, their task will be easier, so they can be more productive in fixing bugs, so we all get to profit.