Community
Participate
Working Groups
Build Identifier: I20100608-0911 (3.6.0) It seems that JSDT gramma does not really support comma operator Reproducible: Always Steps to Reproduce: 1. create a javascript file 2. open it in jsdt editor 3. enter a simple statement with comma expression: var z=(1, 2); expected: non error is highlighted actual: comma is highlighted as error, "Syntax error on tocken ",", in expected" 4. Try context menu -> Source -> Format expected: source is changed according to format rules (e.g. more spaces added) actual: source is not touched by format at all
Created attachment 191789 [details] patch for the parser
Created attachment 191790 [details] parser zip file
Created attachment 191873 [details] Updated Scanner.java for regex handling
Tagged org.eclipse.wst.jsdt.core as v201103242129 before and v201103242136 after.
org.eclipse.wst.jsdt.compiler.tests tagged as v201103242142 (before) and v201103242144(after)
checked into 3.2.4 and HEAD.
*** Bug 341937 has been marked as a duplicate of this bug. ***
Tagging 3.3/HEAD as v201104182003 before.
Tagging 3.3/HEAD as v201104182100 after.
*** Bug 325280 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 325280 has been marked as a duplicate of this bug. *** NOT a duplicate, even if this is still a parsing error. See the bug description. This is a separate issue of the parser related to the presence of optional final commas at end of expression lists in initializers, instead of here within the context of comma-expressions.
(In reply to comment #11) > (In reply to comment #10) > > *** Bug 325280 has been marked as a duplicate of this bug. *** > > NOT a duplicate, even if this is still a parsing error. See the bug > description. Hoaver, the source code proposed for corrct this current bug seems to correctly include the handling of optional commas at end of initializer lists for {object-litterals, } and [new-array-literals, ]. It also seems to correctly accepts empty expressions in those initializers for array litterals (where the comma alone is used to mark an elision to skip an index). Something should be checked for the meaning of final elisions: how many elements are inserted in such [array-litterals, , , , ] ??? Elision makes no sense for object literals where elements can only be indexed by names. However I have not checked if they were invalid. If they are valid, they should just be ignored by the compiler as the indexing name is missing. However, another interesting thing to check is if the following object litteral is valid or not in Javascript/ECMAScript, and how it is interpreted: x = {a:, b:}; I.e. should it insert the properties named "a" and "b" in the new object, but assigning them an unassigned value? I need to reread the ECMAScript specification about this detail: can a ECMAScript object enumerate existing properties whose reading will return an unassigned value? (this case exists for example with variables that have been declared "globally" in a window object or in the text of a function body, but still not assigned, or that have been unset explicitly (instead of assigning them explicitly with a null value); the enumeration of properties in their container still finds those declared but unassigned/unbound variables for the purpose of masking local variables/properties that may be bound in an external but accessible caller context or in the context of a "with(object)..." statement).
