Yup, that would be great as metadata! On Fri, Mar 11, 2016 at 11:26 AM, Jesper Steen Møller <jes...@selskabet.org> wrote:
> Hi Guillaume > > This is not covered by the current code, but it can be added. I guess this > could be set as “metadata” on types, package, properties, methods, and > fields? > > -Jesper > > On 11. mar. 2016, at 11.11, Guillaume Laforge <glafo...@gmail.com> wrote: > > 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> > > > -- 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>
