groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <>
Subject Re: More Antlr4-based Groovy parser status update
Date Fri, 11 Mar 2016 10:26:15 GMT
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?


> On 11. mar. 2016, at 11.11, Guillaume Laforge <> 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 < <>>
> Hi Groovy-Dev
> Here’s another update on the progress on the Antlr4 parser, as maintained on
<> (in the antlr4 branch).
> To play with it, try:
> $ git clone -b antlr4 <>
> $ 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
> 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 <>
> Blog: <>
> Social: @glaforge <> / Google+ <>

View raw message