[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. ---
[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)
[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] [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] [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] [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] [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] [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] [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] [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=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] [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-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=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] [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] [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] [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-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)
[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] [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)
[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] [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)
