I'd say there is no chance they could be mis-parsed. As explained the
variable declaration in for-in resp. for-each loops isn't a proper
ASTVariableDeclaration, therefore visitVariableDeclaration() isn't
called in ParseTreePrinter. visitVariableDeclaration() would ensure
parenthesis are inserted, since it calls mayAddParens().
The calls to mayAddParens() in visitForInStatement() and
visitForEachStatement() may also mislead further generations, because at
that part of a for-in/for-each loop only an ASTExpression can appear.
But you actually don't call mayAddParens() in
visitForVarInStatement()/visitForEachVarStatement() for the
ASTExpression part.
On 2/8/2011 5:54 PM, P T Withington wrote:
There's no chance that the init expression in the others could be mis-parsed by
the bactrace generator inserting comma expressions? Is there a drawback to
adding it to all of them?
On 2011-02-08, at 11:33, André Bargull wrote:
I just started to write an email about the missing mayAddParens() calls, but
you beat me!
The extra calls to mayAddParens() should only be necessary for
visitForVarInStatement() and visitForEachVarStatement(), because only the
ForVarInStatement() resp ForEachVarStatement() grammar productions have this
crippled down variable declaration.
On 2/8/2011 5:26 PM, P T Withington wrote:
Change ptw-20110208-mlv by [email protected] on 2011-02-08 11:23:11 EST
in /Users/ptw/OpenLaszlo/trunk-3
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Unparse expressions in for* initializers correctly
Bugs Fixed: LPP-6975 "for each..in" statement
Technical Reviewer: [email protected] (pending)
QA Reviewer: [email protected] (pending)
Details:
Backtrace mode inserts comma-expressions to track stack. Unparser
must be prepared for them.
Tests:
smokecheck in dhtml+backtrace x {firefox,safari,ie}
Files:
M WEB-INF/lps/server/src/org/openlaszlo/sc/ParseTreePrinter.java
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/ptw-20110208-mlv.tar
