[
https://issues.apache.org/jira/browse/GROOVY-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338416#comment-15338416
]
Paul King edited comment on GROOVY-7868 at 6/22/16 10:23 AM:
-------------------------------------------------------------
Looks like the {{argList}} production in the grammar isn't quite right. It is
probably getting the '>>' confused as a shiftRight operator. Workarounds are to
add a space between the two greater than signs (ugly I know), e.g.:
{code}
{ } as BiConsumer<String, Collection<String> >,
...
{code}
or place the whole argument within round brackets:
{code}
({ } as BiConsumer<String, Collection<String>>),
...
{code}
I should point out that everything is being ultimately parsed correctly (no >>
by mistake or anything) however in deciding whether this is a special super
call or a standard method, the latter is being selected as the parsing path. So
it's lookahead logic that is wrong.
was (Author: paulk):
Looks like the {{argList}} production in the grammar isn't quite right. It is
probably getting the '>>' confused as a shiftRight operator. Workarounds are to
add a space between the two greater than signs (ugly I know), e.g.:
{code}
{ } as BiConsumer<String, Collection<String> >,
...
{code}
or place the whole argument within round brackets:
{code}
({ } as BiConsumer<String, Collection<String>>),
...
{code}
I should point out that everything is being passed correctly (no >> by mistake
or anything) however in deciding whether this is a special super call or a
standard method, the latter is being selected as the parsing path. So it's
lookahead logic that is wrong.
> Calling super constructor with in-line casted Closure param does not compile:
> unexpected "constructor call must be first statement" error
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-7868
> URL: https://issues.apache.org/jira/browse/GROOVY-7868
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.4.6
> Environment: Linux Mint 17.3
> Reporter: Jordan Martinez
> Priority: Minor
>
> Running the following code in Groovy Console should result "successfully"
> with "Could not find matching constructor for 'SomeObject'"
> Instead, code fails with issue "Constructor call must be the first statement
> in a constructor," which is weird because it is...
> Code only runs correctly (e.g. fails in the expected way) in 5 cases:
> * "{} as BiConsumer" line in the super constructor is commented out
> * all arguments past Closure-cast line must be commented out
> * Closure is cast to a different object (say String)
> * the first "Collections.emptyList()" is changed to a different type (say
> String) but the second remains the same
> * The BiConsumer's second generic type (Collection<String>) is changed to a
> different type (say String)
> {code}
> import java.util.function.BiConsumer
> public class ProblematicObject extends SomeObject {
> public ProblematicObject() {
> super(
> { } as BiConsumer<String, Collection<String>>,
>
> Collections.emptyList(),
> Collections.emptyList()
> )
> }
>
> }
> new ProblematicObject()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
