Odd parsing/annotation problem

[ranjitjhala]

See: tests/liquid/pos/objects/obj-02-00.js

somehow the type annotation is getting parsed in as part of the JS and getting rejected by
the isNanoExprStatement (which basically checks that the expression is something we handle.) I cannot tell (easily) what data-constructor is being used to represent the AST corresponding to the parsed annotation.

Should take just a few minutes for @panagosg7 ...

[panagosg7]

What branch are you talking about?

In "heapless" there is just tests/liquid/pos/objects/obj-02.js and tests/liquid/pos/objects/obj-02.js

And I'm not getting the behavior you mentioned.

There is a bug in the parser (as described in the Issues section of the pull request #23)

[ranjitjhala]

whoops, just added the test (heapless)

On Fri, Jan 3, 2014 at 6:04 PM, Panagiotis Vekris
notifications@github.comwrote:

What branch are you talking about?

In "heapless" there is just tests/liquid/pos/objects/obj-02.js and
tests/liquid/pos/objects/obj-02.js

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-31568656
.

[panagosg7]

Problem: It turns out that our type annotations are valid JS regular expressions as far as the parser is concerned (ignoring the fact that they are comments), so what you're seeing is actually a RegExp.

A very short fix just for this example (to keep the ball running) is to add a semicolon right after the object literal to separate it from the next statement (line 8).

However, this is part of a bigger bug in the parser (also menitoned in my latest pull request).

The problem is with parsing an annotation right after an object literal.

In particular, parsing:

var a = { } 
/*@ ..*/

Before parsing comments along with the JS, the parser used these expression tables to parse some expressions including division. So in the above example:

var a =  { } / 

would be parsed as the beginning of a division expression. (I believe) Expression tables do not do backtacking (which is the right thing to do in the first place since no other expression can start with {} /). But now it's impossible to parse this as a comment after an object literal. So, to fix this we would need to have backtracking (try parser) in the case for division so that it could fall back to parsing the obj literal and then the annotation. Adding the semicolon removes the division-disambiguation.

This might be a little more involved than we thought.