At least the JavaCC FAQ gives a straight answer for this problem [1]:
Are semantic actions executed during syntactic lookahead?
No.
Brendan sees 'his mistake' every time he takes a look at the ECMAScript
reference grammar, there is exactly the same nonsense with duplicated
productions. But then he will use the "I only had one day time to invent
JavaScript" joker as an excuse, as always ;-)
[1] http://www.engr.mun.ca/~theo/JavaCC-FAQ/javacc-faq-moz.htm#tth_sEc4.10
On 1/10/2011 5:05 PM, P T Withington wrote:
Approved!
[I guess I can understand why actions can't be executed on lookahead. Too bad
JavaCC doesn't give a warning when you write that... Annoying that you have to
replicate so many productions. I guess I blame Brendan for not picking a
different word for the operator that would have made writing the parser easier.]
On 2011-01-08, at 13:07, André Bargull wrote:
Change bargull-20110108-4LP by barg...@bargull02 on 2011-01-08 18:40:23
in /home/anba/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: fix grammar for "in" operator in lookahead
Bugs Fixed: LPP-6684 (Missing "var" in for-in loop)
Technical Reviewer: ptw
QA Reviewer: (pending)
Details:
JavaCC doesn't execute semantic actions while doing a lookahead, therefore setAllowIn() gets never
called during lookahead. And because of that, getAllowIn() may not report the correct value during
a semantic lookahead in the RelOP() production. Therefore I've added a couple of
"xxxNoIn" productions instead of relying on semantic lookahead to determine when the
"in" operator is allowed.
I've also changed ConditionalExpression() so it only allows
AssignmentExpression() instead of Expression() in the first branch. Changing
the 2nd branch to AssignmentExpression() instead of ConditionalExpression()
caused some lookahead warnings, because AssignmentExpression() isn't compliant
to ECMAScript. Changing AssignmentExpression() to make it ECMAScript compatible
didn't work, because of more differences in CallExpression(),
MemberExpression(), etc. At least the grammar doesn't anymore allow invalid
code, it's now only a bit stricter than the standard. (Also see LPP-9571)
And added missing jjtAccept() methods for ASTModifiedDefinition and
ASTFormalParameterList.
Tests:
test case from bug report compiles
Files:
M WEB-INF/lps/server/sc/src/org/openlaszlo/sc/Parser.jjt
M WEB-INF/lps/server/sc/src/org/openlaszlo/sc/parser/ASTModifiedDefinition.java
M WEB-INF/lps/server/sc/src/org/openlaszlo/sc/parser/ASTFormalParameterList.java
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/bargull-20110108-4LP.tar
