Community
Participate
Working Groups
Some (e.g. jQuery authors) believe that declaring undefined as a variable speeds up calls to it. With JSDT, declaring undefined causes syntax errors: var undefined; //Causes error: "Syntax error on token "var", void expected" var a, undefined; // causes error: "Syntax error on token ",", ; expected"
Would it be possible to remove "undefined" from list of terminals in JavaScript grammar (js.g)?
Created attachment 155088 [details] patch Removing "undefined" token detection in Scanner.java does the trick. Errors don't appear any more but code still compiles and "undefined" still looks like keyword (bold font). In attached patch I also commented out several more places where UndefinedToken is referenced. Probably UndefinedLiteral should also be removed. Could you review this approach?
Any taker to review this patch? :-)
Patch looks simple, though I don't know the side effects of tampering with the TerminalTokens list. I don't really like the idea of changing something that was auto-generated by our grammar tool. The comments of that file says: /** * IMPORTANT NOTE: These constants are dedicated to the internal Scanner implementation. * It is mirrored in org.eclipse.wst.jsdt.core.compiler public package where it is API. * The mirror implementation is using the backward compatible ITerminalSymbols constant * definitions (stable with 2.0), whereas the internal implementation uses TerminalTokens * which constant values reflect the latest parser generation state. */ /** * Maps each terminal symbol in the java-grammar into a unique integer. * This integer is used to represent the terminal when computing a parsing action. * * Disclaimer : These constant values are generated automatically using a Java * grammar, therefore their actual values are subject to change if new keywords * were added to the language (for instance, 'assert' is a keyword in 1.4). */
Comment on attachment 155088 [details] patch Obsoleting Jacek's patch for tracking purposes.
Chris, so are you suggesting to change the grammar file rather than auto-generated code? Will it be possible to re-run parser-generator on updated grammar? I thought that it's no possible due to other code changes that already went into generated files... but I might be wrong. btw. now even VisualStudio 2010 supports jQuery as part of JavaScript support :-(
This looks similar to bug 277165, which is about "fields" called undefined on objects.
I think we would like to update the grammar file at some point in the next release. We are too far down the road in 3.2 to do a change of that size at this time. There is a lot of stuff that needs updating in there.
*** Bug 318890 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 318890 has been marked as a duplicate of this bug. *** Will this planned for a future release of WTP ?(In reply to comment #8) > I think we would like to update the grammar file at some point in the next > release. We are too far down the road in 3.2 to do a change of that size at > this time. > There is a lot of stuff that needs updating in there. Hello, does it mean we can expect this in WTP 3.2.1? Thank you.
No. If you look at the target milestone field it is currently set to "Future" which means we have no planned date for including this fix.
OK, i looked also at comment #8 "...at some point in the next release. " A) So practically if using jquery files, there is no way to not have errors in these files, right? B) pls confirm that even if the jquery files where parsed without the present errors then, from the content-assist's standpoint (make appear the famous $() on Ctrl + Space) this would anyway require a special solution (adding those .fcrec files that jquery plugin for JSDT provides) because the functions and objects in jquery are either added dynamically or declared as local variables inside an (anonymous) function body (that gets called): (function(){...})() JSDT does not support content-assist for what is added dynamically or declared inside a non-constructor function body.
*** This bug has been marked as a duplicate of bug 324416 ***
