-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lift restrictions on the left-hand-side in the ES5 parser #40
Comments
Instead what we need is to re-write the |
Actually I might have misunderstood what you mean above, you probably have the right idea, but yeah, just to be clear, we should not change |
Understood. I'll be careful with the parser. The thing is, restricting the left-hand-side expression by the AST constructor is not an option, because even non-LeftHandSide expressions can be targets of an assignment, provided they are in parentheses. Speaking of left-recursion and choking up on parsing jQuery: performance is, indeed, an important characteristic of a parser, though I haven't paid too much attention to it before. @philipnilsson, I understand that you have done some performance benchmarking for language-ecmascript before. Do you think it makes sense to add some performance benchmarks to the library? I'm not sure what's the best way to integrate it in the package (as another test-suite) and which library to use (I hear |
Not really benchmarks though. The parser used to choke with an out-of-memory error. The performance has been "tuned" to not do that, but not any more. |
I have finally gotten my head around the solution space for the issue. In short, precise determination of Specifically, the code in ParserState needs to be refactored. Need to abstract from the type of the annotation in |
…etermine whether they were parenthesized. Also started abstracting withPos and similar to accept rich annotations
I'm not sure fixing this makes sense anymore: the ECMAScript 6 standard now imposes additional syntactic restrictions (IsValidSimpleAssignmentTarget in Static Semantics) that seem to be equivalent to the restrictions we already have. While we are not working on a extending the parser to ECMAScript 6, being too pedantic about the 5th edition of the specification makes no sense if the newer edition already imposes those restrictions. I'll give a few weeks for comments. If noone opposes, I'll close this issue as a WONTFIX. |
Agreed. |
restrictions. So, the test case is no longer valid.
Right now the expressions that are used as targets of assignments are validated against the
validLHS
function. While there is reason in that (all other expressions would raise aReferenceError
at run-time), the specification is less restrictive on this matter, and we'd like to follow it closely.Thus,
assignmentExpressionGen
should be rewritten to expect anyLeftHandSideExpression
(as defined by the spec) instead of just a variable or a field reference.When issue #41 is closed we could relax the restriction in the spec to allow error recovery.
The text was updated successfully, but these errors were encountered: