[jira] [Resolved] (GROOVY-9936) Difference between Antlr2 and parrot parsers for variable declaration optimisation

["Paul King (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King resolved GROOVY-9936.
-------------------------------
    Fix Version/s: 4.0.0-alpha-3
                   3.0.8
       Resolution: Fixed

Proposed PR merged. Since we decided that the behavior in Groovy 3 for the edge cases unsurfaced by this issue was unexpected, and hence a regression compared to Groovy 2.x, I have also merged into the GROOVY_3_0_X branch and updated the release notes.

> Difference between Antlr2 and parrot parsers for variable declaration optimisation
> ----------------------------------------------------------------------------------
>
>                 Key: GROOVY-9936
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9936
>             Project: Groovy
>          Issue Type: Bug
>          Components: parser-antlr4
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 3.0.8, 4.0.0-alpha-3
>
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> As an optimisation for parsing, both parsers treat statements like:
> {code}
> int var1
> Foo var2
> Bar var3
> {code}
> as variable declarations due to the starting capital letter of the first term (for non-primitives).
> And the following are treated by both parsers as command expressions:
> {code}
> foo x
> bar y
> {code}
> due to the lowercase starting letter of the first term. If a class starts with a lowercase letter (valid though not conventional) the workaround where a variable declaration is desired is to use something like:
> {code}
> import myClass as MyClass
> MyClass foo
> {code}
> A difference in behavior can be noted for cases starting with underscore or dollar (the only other characters available for the first letter of a class name):
> {code}
> _foo bar
> $bar baz
> {code}
> These were command expressions for the old parser and are being coerced to variable declarations in the Parrot parser.
> We need to decide whether to alter these last two cases for backwards compatibility or whether we see this as a breaking change which better aligns with the Java specification.
> I propose we opt for backwards compatibility since the above mentioned workaround would apply equally for classes with these starting characters, whereas renaming a method starting with these characters is more complicated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)