By the way, I had a question (unrelated to the below thread, but related to the grammar) :-)
Do you keep the comment information? It's something we've always said we should support, and it would tremendously help making a less hackish groovydoc tool. Having AST nodes for JavaDoc comments would really be great. Guillaume On Sun, Feb 28, 2016 at 12:55 PM, Jesper Steen Møller <jes...@selskabet.org> wrote: > Hi Groovy-Dev > > Here’s another update on the progress on the Antlr4 parser, as maintained > on *https://github.com/jespersm/groovy.git > <https://github.com/jespersm/groovy.git>* (in the *antlr4* branch). > To play with it, try: > > $ git clone -b antlr4 https://jespe...@github.com/jespersm/groovy.git > $ cd groovy > $ gradle -PuseAntlr4=true console > > > I’ve fixed a number of issues: > > - Support method pointer operator > - Attributes/method/property names as strings/gstrings > - Real support for unary plus and minus (mimics old parser’s behaviour) > - Compilation units not ending with semicolon or newline > - Slashy strings could span lines, confusing division statements and > comments > > I can now explore the new grammar and AST building using the Console, > which is fun, but it’s very easy to find unsupported constructs. Mapping > out the full Groovy grammar from the documentation alone is quite a task. > Just today, I discovered lacking support for ‘assert’ and for > ’super’-calls. The smaller issues currently are: > > - assert > - super() > - Full Unicode letter support for identifiers > - Support identifiers as property names and map literal entry names > > > The bigger issue is with converting the ASTBuilder to pure Java, a task I > havn’t started yet. Actually, this poses a different question for AST > generation: Whether to switch from tree-walking the parse tree (so whole > tree must be kept in memory), to the listener-based approach, where the AST > is built mostly bottom-up, ensuring smaller memory footprint. > > So you can help me with a couple of answers: > > - Memory: Is this an issue I should be focusing on — and is there a > test to baseline against? > - I’ve discovered a small issue with unary syntax. Currently, nested > unary expressions are not supported without parenthesis: Try e.g. - -1 or + > -1. Is this intentional, or just an artifact of the precedence-refactored > Java grammar? > > > -Jesper > > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Product Ninja & Advocate at Restlet <http://restlet.com> Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
