Fails on all TC39 early errors

[ghost]

This ECMAScript parser fails on all Fails on all TC39 early errors, and mostly all TC39 tests.

[hzoo]

Thanks for reporting? I know we wanted to setup test262 - would you want to help do that? We certainly do have lots of bugs and spec-complaint issues. There's not really anything actionable here since this is too broad of an issue.

[xtuc]

See babel/babel#4987 for the test suite setup.

[hzoo]

Cool, can refer to that and we will try to make progress.

[ghost]

I will break my silence :)

@hzoo Implementing such things will take a huge amount of time, and need rewrite of current code base, and you also would need a "scope tracker" to catch this errors. This is not done in one day. I have in depth experience with this process because I actually made my own ECMA parser that is 100% spec compatible. Hopefully it will be released to public by next month. A lot of code cleanup to fix, but everything passes. And in the development process I also discovered that Babylon parses tests that is invalid when it comes to specs. This you will see if you try to parse many of the other TC39 tests - not only early-errors.

@kuraga Kewlr has nothing to do with a Ecma parser. That script does what it say it should do. Anyway. Do you need the source code?

[ghost]

@hzoo If I'm not mistaken, the only usecase of Babylon is Babel? So the question would also be if it's needed to cover the specs 100%. That almost all TC39-262 pass and pass-explicit tests should pass, I take for granted. I choose to say allmost because if you deep dive into this, you will be surprised to learn that some of the TC39-262 tests itself violating the specs.

And also semantic and syntactic errors should be catched.

function l() { '\12'; 'use strict' }
for (a i\u0074 e) break;
function* l() { ([e=yield])=>12 } // semantic or syntactic

For this errors, you need to rethink the location tracker because where in e.g. function* l() { ([e=yield])=>12 } is the invalid code located? In the middle, the end or in the beginning? That's valuable info to have when you throw an error. And if the error occur at the beginning, or in the middle, do you really need to excute the rest of it?

And mixed into all this. You need to think about the performance too, because it can cause huge performance hits to track all this errors :) And Babylon isn't the fastest ECMA parser I have seen either - but among the fastest it is.

But once again. This will take a huge amount of time to fix, but it's possible. And in the end if you fix all this, and keep an eye on the performance, you hopefully will get a performance hit too. Something like this:

-----------START---------
 source:  angular.js
0.06869627602631578 '(*--*)' // my parser
0.20692217294117649 '(esprima)'
0.14585379580952385 '(acorn)'
------------DONE---------

-----------START---------
 source:  jquery-1.9.1.js
0.02817654231818182 '(*--*)'  // my parser
0.07587770097222221 '(esprima)'
0.06680029882500002 '(acorn)'
------------DONE---------