[jira] [Resolved] (GROOVY-8732) @CompileStatic refers to private field in parent class
[ https://issues.apache.org/jira/browse/GROOVY-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8732. --- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.5.2 3.0.0-alpha-4 Proposed PR resolved. I'll try to add a test later but resolving now for inclusion on 2.5.2. > @CompileStatic refers to private field in parent class > -- > > Key: GROOVY-8732 > URL: https://issues.apache.org/jira/browse/GROOVY-8732 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1 >Reporter: Lóránt Pintér >Assignee: Paul King >Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.2 > > > {code} > import groovy.transform.CompileStatic > @CompileStatic > interface Thing { > void call() > } > @CompileStatic > class ThingImpl implements Thing { > void call() {} > } > @CompileStatic > class Parent { > private final ThingImpl thing > public Thing getThing() { null } > } > @CompileStatic > class Child extends Parent { > public void doSomething() { > thing.call() > } > } > {code} > Compile via: {{groovyc Example.groovy}}. > The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but > then ends up referring to the returned value according to the private field's > type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type > ({{Thing}}). The private field from {{Parent}} (or its type) should not be > visible to {{Child}} at all. > {code} > public void doSomething(); > descriptor: ()V > flags: (0x0001) ACC_PUBLIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokevirtual #20 // Method > Parent.getThing:()LThing; > 4: checkcast #22 // class ThingImpl > 7: invokevirtual #25 // Method ThingImpl.call:()V > 10: aconst_null > 11: pop > 12: return > {code} > This is causing now problems for Gradle plugins compiled against Grade 4.9 or > before trying to run on Gradle 4.9, because we've made a change to an > internal type (`ProjectInternal`) that ended up being referred to via this > bug in compiled and released code. See > https://github.com/gradle/gradle/issues/6027 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575606#comment-16575606 ] Paul King commented on GROOVY-8737: --- It's trickier than it looks. For your example, the two param variant actually has Object[] for its last argument so varargs would apply to that as well, so is it a perfect match? > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8732) @CompileStatic refers to private field in parent class
[ https://issues.apache.org/jira/browse/GROOVY-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575591#comment-16575591 ] ASF GitHub Bot commented on GROOVY-8732: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/781 > @CompileStatic refers to private field in parent class > -- > > Key: GROOVY-8732 > URL: https://issues.apache.org/jira/browse/GROOVY-8732 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1 >Reporter: Lóránt Pintér >Priority: Major > > {code} > import groovy.transform.CompileStatic > @CompileStatic > interface Thing { > void call() > } > @CompileStatic > class ThingImpl implements Thing { > void call() {} > } > @CompileStatic > class Parent { > private final ThingImpl thing > public Thing getThing() { null } > } > @CompileStatic > class Child extends Parent { > public void doSomething() { > thing.call() > } > } > {code} > Compile via: {{groovyc Example.groovy}}. > The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but > then ends up referring to the returned value according to the private field's > type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type > ({{Thing}}). The private field from {{Parent}} (or its type) should not be > visible to {{Child}} at all. > {code} > public void doSomething(); > descriptor: ()V > flags: (0x0001) ACC_PUBLIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokevirtual #20 // Method > Parent.getThing:()LThing; > 4: checkcast #22 // class ThingImpl > 7: invokevirtual #25 // Method ThingImpl.call:()V > 10: aconst_null > 11: pop > 12: return > {code} > This is causing now problems for Gradle plugins compiled against Grade 4.9 or > before trying to run on Gradle 4.9, because we've made a change to an > internal type (`ProjectInternal`) that ended up being referred to via this > bug in compiled and released code. See > https://github.com/gradle/gradle/issues/6027 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #781: GROOVY-8732: @CompileStatic refers to private fiel...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/781 ---
[jira] [Created] (GROOVY-8740) groovy.util.CliBuilder doesn't handle parse errors correctly
Роман Донченко created GROOVY-8740: -- Summary: groovy.util.CliBuilder doesn't handle parse errors correctly Key: GROOVY-8740 URL: https://issues.apache.org/jira/browse/GROOVY-8740 Project: Groovy Issue Type: Bug Components: groovy-jdk Affects Versions: 2.5.1 Reporter: Роман Донченко In Groovy 2.5, {{groovy.util.CliBuilder}} is a wrapper that delegates to {{groovy.cli.commons.CliBuilder}}. However, this wrapper doesn't correctly handle the case when the arguments fail to be parsed. Here's how it works with the real {{CliBuilder}}: {code:java} groovy:000> options = new groovy.cli.commons.CliBuilder(stopAtNonOption: false).parse(['-x']) error: Unrecognized option: -x usage: groovy ===> null{code} And here's what happens with the wrapper: {code:java} groovy:000> options = new groovy.util.CliBuilder(stopAtNonOption: false).parse(['-x']) error: Unrecognized option: -x usage: groovy ===> groovy.util.OptionAccessor@6fc3e1a4 groovy:000> options.arguments() ERROR java.lang.NullPointerException: Cannot invoke method arguments() on null object{code} I get an object that pretends to be {{null}}, but isn't. So I can't determine whether the parsing was successful or not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-3964) Strange exception in GroovyConsole
[ https://issues.apache.org/jira/browse/GROOVY-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575545#comment-16575545 ] Paul King commented on GROOVY-3964: --- Just adding in another link with some more details: https://bugs.openjdk.java.net/browse/JDK-6606476 > Strange exception in GroovyConsole > -- > > Key: GROOVY-3964 > URL: https://issues.apache.org/jira/browse/GROOVY-3964 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 1.7-rc-2 > Environment: Mac OS 10.6.2 > Java 1.6.0_17 >Reporter: Peter Niederwieser >Priority: Major > > Does Groovy Console really use a component from IDEA? > [pniederw:~]$ groovyConsole > Exception "java.lang.ClassNotFoundException: > com.intellij.openapi.editor.RawText"while constructing DataFlavor for: > application/x-java-jvm-local-objectref; > class=com.intellij.openapi.editor.RawText > Exception "java.lang.ClassNotFoundException: > com.intellij.openapi.editor.RawText"while constructing DataFlavor for: > application/x-java-jvm-local-objectref; > class=com.intellij.openapi.editor.RawText > Exception "java.lang.ClassNotFoundException: > com.intellij.codeInsight.editorActions.FoldingTransferableData$FoldingData"while > constructing DataFlavor for: application/x-java-jvm-local-objectref; > class=com.intellij.codeInsight.editorActions.FoldingTransferableData$FoldingData > Exception "java.lang.ClassNotFoundException: > com.intellij.codeInsight.editorActions.FoldingTransferableData$FoldingData"while > constructing DataFlavor for: application/x-java-jvm-local-objectref; > class=com.intellij.codeInsight.editorActions.FoldingTransferableData$FoldingData > Exception "java.lang.ClassNotFoundException: > com.intellij.codeInsight.editorActions.ReferenceTransferableData$ReferenceData"while > constructing DataFlavor for: application/x-java-jvm-local-objectref; > class=com.intellij.codeInsight.editorActions.ReferenceTransferableData$ReferenceData > Exception "java.lang.ClassNotFoundException: > com.intellij.codeInsight.editorActions.ReferenceTransferableData$ReferenceData"while > constructing DataFlavor for: application/x-java-jvm-local-objectref; > class=com.intellij.codeInsight.editorActions.ReferenceTransferableData$ReferenceData -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8739) groovysh can't evaluate slashy strings
Роман Донченко created GROOVY-8739: -- Summary: groovysh can't evaluate slashy strings Key: GROOVY-8739 URL: https://issues.apache.org/jira/browse/GROOVY-8739 Project: Groovy Issue Type: Bug Components: Groovysh Affects Versions: 2.5.1, 3.0.0-alpha-3 Reporter: Роман Донченко If you type in a slashy string into groovysh, it expects more input instead of evaluating it: {code:java} groovy:000> /abc/ groovy:001{code} I know slashy strings can be ambiguous, but that shouldn't be an issue here, since an expression can't begin with a division operator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8739) groovysh can't evaluate slashy strings
[ https://issues.apache.org/jira/browse/GROOVY-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Роман Донченко updated GROOVY-8739: --- Description: If you type a slashy string into groovysh, it expects more input instead of evaluating it: {code:java} groovy:000> /abc/ groovy:001{code} I know slashy strings can be ambiguous, but that shouldn't be an issue here, since an expression can't begin with a division operator. was: If you type in a slashy string into groovysh, it expects more input instead of evaluating it: {code:java} groovy:000> /abc/ groovy:001{code} I know slashy strings can be ambiguous, but that shouldn't be an issue here, since an expression can't begin with a division operator. > groovysh can't evaluate slashy strings > -- > > Key: GROOVY-8739 > URL: https://issues.apache.org/jira/browse/GROOVY-8739 > Project: Groovy > Issue Type: Bug > Components: Groovysh >Affects Versions: 3.0.0-alpha-3, 2.5.1 >Reporter: Роман Донченко >Priority: Minor > > If you type a slashy string into groovysh, it expects more input instead of > evaluating it: > {code:java} > groovy:000> /abc/ > groovy:001{code} > I know slashy strings can be ambiguous, but that shouldn't be an issue here, > since an expression can't begin with a division operator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574810#comment-16574810 ] Patric Bechtel commented on GROOVY-8737: Couldn't we just stop trying vararg variants if we *have* a perfect match already? > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8732) @CompileStatic refers to private field in parent class
[ https://issues.apache.org/jira/browse/GROOVY-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574756#comment-16574756 ] Paul King commented on GROOVY-8732: --- After the above PR the bytecode for your example becomes: {code} ALOAD 0 CHECKCAST Child INVOKEVIRTUAL Child.getThing ()LThing; INVOKEINTERFACE Thing.call ()V (itf) ACONST_NULL POP RETURN {code} > @CompileStatic refers to private field in parent class > -- > > Key: GROOVY-8732 > URL: https://issues.apache.org/jira/browse/GROOVY-8732 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1 >Reporter: Lóránt Pintér >Priority: Major > > {code} > import groovy.transform.CompileStatic > @CompileStatic > interface Thing { > void call() > } > @CompileStatic > class ThingImpl implements Thing { > void call() {} > } > @CompileStatic > class Parent { > private final ThingImpl thing > public Thing getThing() { null } > } > @CompileStatic > class Child extends Parent { > public void doSomething() { > thing.call() > } > } > {code} > Compile via: {{groovyc Example.groovy}}. > The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but > then ends up referring to the returned value according to the private field's > type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type > ({{Thing}}). The private field from {{Parent}} (or its type) should not be > visible to {{Child}} at all. > {code} > public void doSomething(); > descriptor: ()V > flags: (0x0001) ACC_PUBLIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokevirtual #20 // Method > Parent.getThing:()LThing; > 4: checkcast #22 // class ThingImpl > 7: invokevirtual #25 // Method ThingImpl.call:()V > 10: aconst_null > 11: pop > 12: return > {code} > This is causing now problems for Gradle plugins compiled against Grade 4.9 or > before trying to run on Gradle 4.9, because we've made a change to an > internal type (`ProjectInternal`) that ended up being referred to via this > bug in compiled and released code. See > https://github.com/gradle/gradle/issues/6027 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574749#comment-16574749 ] Paul King commented on GROOVY-8737: --- Yes, parts and names are the last parameter for those variants. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574740#comment-16574740 ] Patric Bechtel commented on GROOVY-8737: Yeah, ok ;) But given the principle of least surprise, this is quite surprising. I didn't know that anyone was using multiple varargs - wasn't it constrained to the last parameter? > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
[ https://issues.apache.org/jira/browse/GROOVY-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-8738. --- > Bump picocli version to 3.5.0 from 3.3.0 > > > Key: GROOVY-8738 > URL: https://issues.apache.org/jira/browse/GROOVY-8738 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.1 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.2 > > > Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
[ https://issues.apache.org/jira/browse/GROOVY-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved GROOVY-8738. - Resolution: Fixed > Bump picocli version to 3.5.0 from 3.3.0 > > > Key: GROOVY-8738 > URL: https://issues.apache.org/jira/browse/GROOVY-8738 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.1 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.2 > > > Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574727#comment-16574727 ] Paul King commented on GROOVY-8737: --- Well, both scenarios apply. With varargs, I can supply 0 parts for the second variant 0 names for the 3rd variant. In that scenario all three methods would match. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
Remko Popma created GROOVY-8738: --- Summary: Bump picocli version to 3.5.0 from 3.3.0 Key: GROOVY-8738 URL: https://issues.apache.org/jira/browse/GROOVY-8738 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.2 Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574721#comment-16574721 ] Patric Bechtel edited comment on GROOVY-8737 at 8/9/18 11:45 AM: - I always understood that (useful) feature as looking at the very last parameter and only if there's more parameters in the call than the method has. This case is reverse IMHO: There's two parameters given, and groovy is trying to match more to put zero-sized arrays there. Which is weird. was (Author: patric42): I always understood that (useful) feature as looking at the very last parameter and only if there's more parameters in the call than to method has. This case is reverse IMHO: There's two parameters given, and groovy is trying to match more to put zero-sized arrays there. Which is weird. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574721#comment-16574721 ] Patric Bechtel edited comment on GROOVY-8737 at 8/9/18 11:45 AM: - I always understood that (useful) feature as looking at the very last parameter and only if there's more parameters in the call than to method has. This case is reverse IMHO: There's two parameters given, and groovy is trying to match more to put zero-sized arrays there. Which is weird. was (Author: patric42): I always understood that (useful) feature as looking at the very last parameter and only if there's more parameters to match. This case is reverse IMHO: There's two parameters given, and groovy is trying to match more to put zero-sized arrays there. Which is weird. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574721#comment-16574721 ] Patric Bechtel commented on GROOVY-8737: I always understood that (useful) feature as looking at the very last parameter and only if there's more parameters to match. This case is reverse IMHO: There's two parameters given, and groovy is trying to match more to put zero-sized arrays there. Which is weird. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574703#comment-16574703 ] Paul King commented on GROOVY-8737: --- Groovy allows you to use an array to indicate varargs. It's something from JDK 1.4 days in fact but has so far always been kept for backwards compatibility. And with varargs you can have no supplied args hence they fall back to the same signature. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[ https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patric Bechtel updated GROOVY-8737: --- Description: Given two classes as follows {code:java} @groovy.transform.CompileStatic class A { public static String msg( String key, Object[] args ) { "key=$key, args=$args" } public static String msg( String key, Object[] args, Object[] parts ) { "key=$key, args=$args, parts=$parts" } public static String msg( String key, Object[] args, String[] names ) { "key=$key, args=$args, names=$names" } } {code} and {code:java} @groovy.transform.CompileStatic public class B { public static void main( String[] args ) { println A.msg( 'hello', [ 'world' ] as Object[] ) } } {code} will not compile with the error {noformat} B.groovy: 4: [Static type checking] - Reference to method is ambiguous. Cannot choose between [java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.Object[]), java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] @ line 4, column 15. println A.msg( 'hello', [ 'world' ] as Object[] ) {noformat} Though there's a perfect match for the called method, it tries to choose one of the longer signatures. was: Given two classes as follows {code:java} @groovy.transform.CompileStatic class A { public static String msg( String key, Object[] args ) { "key=$key, args=$args" } public static String msg( String key, Object[] args, Object[] parts ) { "key=$key, args=$args, parts=$parts" } public static String msg( String key, Object[] args, String[] names ) { "key=$key, args=$args, names=$names" } } {code} and {code:java} @groovy.transform.CompileStatic public class B { public static void main( String[] args ) { println A.msg( 'hello', [ 'world' ] as Object[] ) } } {code} will not compile with the error {noformat} B.groovy: 4: [Static type checking] - Reference to method is ambiguous. Cannot choose between [java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.Object[]), java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] @ line 4, column 15. println A.msg( 'hello', [ 'world' ] as Object[] ) {noformat} Though there's a perfect match for the called method, it tries to choose one of the longer signatures. > STC Method resolution fails if other methods with more parameters exist > --- > > Key: GROOVY-8737 > URL: https://issues.apache.org/jira/browse/GROOVY-8737 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1 > Environment: Ubuntu 18.04, Java 8u181 >Reporter: Patric Bechtel >Priority: Major > > Given two classes as follows > {code:java} > @groovy.transform.CompileStatic > class A { > public static String msg( String key, Object[] args ) { "key=$key, > args=$args" } > public static String msg( String key, Object[] args, Object[] parts ) { > "key=$key, args=$args, parts=$parts" } > public static String msg( String key, Object[] args, String[] names ) { > "key=$key, args=$args, names=$names" } > } > {code} > and > {code:java} > @groovy.transform.CompileStatic > public class B { > public static void main( String[] args ) { > println A.msg( 'hello', [ 'world' ] as Object[] ) > } > } > {code} > will not compile with the error > {noformat} > B.groovy: 4: [Static type checking] - Reference to method is ambiguous. > Cannot choose between [java.lang.String A#msg(java.lang.String, > java.lang.Object[], java.lang.Object[]), java.lang.String > A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] > @ line 4, column 15. > println A.msg( 'hello', [ 'world' ] as Object[] ) > {noformat} > Though there's a perfect match for the called method, it tries to choose one > of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
Patric Bechtel created GROOVY-8737: -- Summary: STC Method resolution fails if other methods with more parameters exist Key: GROOVY-8737 URL: https://issues.apache.org/jira/browse/GROOVY-8737 Project: Groovy Issue Type: Bug Components: Static compilation Affects Versions: 2.5.1, 3.0.0-alpha-3, 2.4.15 Environment: Ubuntu 18.04, Java 8u181 Reporter: Patric Bechtel Given two classes as follows {code:java} @groovy.transform.CompileStatic class A { public static String msg( String key, Object[] args ) { "key=$key, args=$args" } public static String msg( String key, Object[] args, Object[] parts ) { "key=$key, args=$args, parts=$parts" } public static String msg( String key, Object[] args, String[] names ) { "key=$key, args=$args, names=$names" } } {code} and {code:java} @groovy.transform.CompileStatic public class B { public static void main( String[] args ) { println A.msg( 'hello', [ 'world' ] as Object[] ) } } {code} will not compile with the error {noformat} B.groovy: 4: [Static type checking] - Reference to method is ambiguous. Cannot choose between [java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.Object[]), java.lang.String A#msg(java.lang.String, java.lang.Object[], java.lang.String[])] @ line 4, column 15. println A.msg( 'hello', [ 'world' ] as Object[] ) {noformat} Though there's a perfect match for the called method, it tries to choose one of the longer signatures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8732) @CompileStatic refers to private field in parent class
[ https://issues.apache.org/jira/browse/GROOVY-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574464#comment-16574464 ] ASF GitHub Bot commented on GROOVY-8732: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/781 GROOVY-8732: @CompileStatic refers to private field in parent class Currently JavaBean style getters aren't recognised before some preliminary provisions are made for the case of accessing the private field in places where that is allowed. The change is just not to proceed with those provisions if the JavaBean getter is detected. You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8732 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/781.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #781 commit 2b4c33317f34d52c5fbeb0846639597a5f6b86fe Author: Paul King Date: 2018-08-09T08:12:08Z GROOVY-8732: @CompileStatic refers to private field in parent class Currently JavaBean style getters aren't recognised before some preliminary provisions are made for the case of accessing the private field in places where that is allowed. The change is just not to proceed with those provisions if the JavaBean getter is detected. > @CompileStatic refers to private field in parent class > -- > > Key: GROOVY-8732 > URL: https://issues.apache.org/jira/browse/GROOVY-8732 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1 >Reporter: Lóránt Pintér >Priority: Major > > {code} > import groovy.transform.CompileStatic > @CompileStatic > interface Thing { > void call() > } > @CompileStatic > class ThingImpl implements Thing { > void call() {} > } > @CompileStatic > class Parent { > private final ThingImpl thing > public Thing getThing() { null } > } > @CompileStatic > class Child extends Parent { > public void doSomething() { > thing.call() > } > } > {code} > Compile via: {{groovyc Example.groovy}}. > The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but > then ends up referring to the returned value according to the private field's > type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type > ({{Thing}}). The private field from {{Parent}} (or its type) should not be > visible to {{Child}} at all. > {code} > public void doSomething(); > descriptor: ()V > flags: (0x0001) ACC_PUBLIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokevirtual #20 // Method > Parent.getThing:()LThing; > 4: checkcast #22 // class ThingImpl > 7: invokevirtual #25 // Method ThingImpl.call:()V > 10: aconst_null > 11: pop > 12: return > {code} > This is causing now problems for Gradle plugins compiled against Grade 4.9 or > before trying to run on Gradle 4.9, because we've made a change to an > internal type (`ProjectInternal`) that ended up being referred to via this > bug in compiled and released code. See > https://github.com/gradle/gradle/issues/6027 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #781: GROOVY-8732: @CompileStatic refers to private fiel...
GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/781 GROOVY-8732: @CompileStatic refers to private field in parent class Currently JavaBean style getters aren't recognised before some preliminary provisions are made for the case of accessing the private field in places where that is allowed. The change is just not to proceed with those provisions if the JavaBean getter is detected. You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8732 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/781.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #781 commit 2b4c33317f34d52c5fbeb0846639597a5f6b86fe Author: Paul King Date: 2018-08-09T08:12:08Z GROOVY-8732: @CompileStatic refers to private field in parent class Currently JavaBean style getters aren't recognised before some preliminary provisions are made for the case of accessing the private field in places where that is allowed. The change is just not to proceed with those provisions if the JavaBean getter is detected. ---