[jira] [Commented] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786185#comment-17786185
]
Paul King commented on GROOVY-11222:
[~blackdrag], I wasn't sure which change you were referring to?
I remember the pre-Groovy 2 changes for resolving, e.g. we didn't look up
lowercase names for star imports, requiring an explicit import for that case
(but then allowing the lowercase in most places).
I also remember a Groovy 3 change which I think was needed for the grammar (I
believe for efficiency reasons but it might have been an ambiguity issue) but I
believe was only for method return type:
[https://github.com/apache/groovy/commit/d3c68531]
The fix for that as mentioned is an import alias which can also be done in the
same file (in case that wasn't obvious in Jochen's earlier comment):
{code:java}
record person(String firstName, String lastName) { }
import person as Person
Person createPerson(String fn, String ln) {
new Person(fn, ln)
}
{code}
I thought that was the issue at play here but perhaps there was another issue
as well?
If it's just the issue above, then the impact on DSLs only impacts places where
you need strongly-typed return types for method declarations. In some cases,
you could use dynamic return types or extract method definitions to separate
files to keep such noise out of your DSLs.
In any case, we wouldn't role back that change unless we found some other way
to make that case very efficient.
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> :
[jira] [Comment Edited] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786018#comment-17786018
]
Paul King edited comment on GROOVY-11222 at 11/15/23 6:01 AM:
--
We decided to make a breaking change in Groovy 4 here. Thus this is no bug and
expected. The GLS only talks about identifiers, not class names. I guess it
needs an update here. the reason for this change is that there are problems
with the name resolution leading to very long compilation times in which the
compiler basically looks for non-existing classes. This is because for example
"def foo = String" is valid in Groovy. It is not the only example causing
problems, just the most easy to understand. Using 3rd party libraries or
generated code in groovy, that is not following the conventions can be worked
around. Groovy supports import aliases. Thus you can do "import
com.generated.something.foo as Foo" and if you then do "def foo = Foo" it will
resolve to the class com.generated.something.foo. This alias can be used
anywhere, also in implements or extends.
was (Author: blackdrag):
We decided to make a breaking change in Groovy 4 here. Thus this is no bug and
expected. The GSL only talks about identifiers, not class names. I guess it
needs an update here. the reason for this change is that there are problems
with the name resolution leading to very long compilation times in which the
compiler basically looks for non-existing classes. This is because for example
"def foo = String" is valid in Groovy. It is not the only example causing
problems, just the most easy to understand. Using 3rd party libraries or
generated code in groovy, that is not following the conventions can be worked
around. Groovy supports import aliases. Thus you can do "import
com.generated.something.foo as Foo" and if you then do "def foo = Foo" it will
resolve to the class com.generated.something.foo. This alias can be used
anywhere, also in implements or extends.
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
>
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786156#comment-17786156
]
Paul King commented on GROOVY-8254:
---
Stricter sounds good to me:
* An error for regular imports with the same basename as a top-level type in
the CU
* For an alias import, the basename of the type can match a top-level type in
the CU but not the alias name
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
> Fix For: 5.0.0-alpha-3
>
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786100#comment-17786100
]
Eric Milles commented on GROOVY-8254:
-
JLS 7.5.1 says it’s an error to import a name that is the same as a top-level
type in the compilation unit. So maybe we should go there. Groovy does the last
name wins thing, but maybe it is time to be a bit stricter.
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
> Fix For: 5.0.0-alpha-3
>
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786089#comment-17786089
]
Eric Milles commented on GROOVY-8254:
-
As it was implemented, alias imports gained precedence over local names and
regular imports. This could be revisited to restore the equivalent treatment of
alias and regular imports. The difference observed between same-file and
same-package names would need to be looked at. [~paulk] thoughts?
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
> Fix For: 5.0.0-alpha-3
>
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786073#comment-17786073 ] Eric Milles commented on GROOVY-8299: - That's great news! Should this ticket be marked as resolved or are you working on private/static methods now? > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > Time Spent: 8h > Remaining Estimate: 0h > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786021#comment-17786021 ] Jochen Theodorou commented on GROOVY-8299: -- What is missing is "GROOVY-10060 Support static & private interface methods". As for the default methods itself, they are now the same as in Java. This includes Java using them from Groovy or reverse, Groovy/Java calling them defined in Java or Groovy and joint compilation. > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > Time Spent: 8h > Remaining Estimate: 0h > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou closed GROOVY-11222.
-
Resolution: Won't Fix
We decided to make a breaking change in Groovy 4 here. Thus this is no bug and
expected. The GSL only talks about identifiers, not class names. I guess it
needs an update here. the reason for this change is that there are problems
with the name resolution leading to very long compilation times in which the
compiler basically looks for non-existing classes. This is because for example
"def foo = String" is valid in Groovy. It is not the only example causing
problems, just the most easy to understand. Using 3rd party libraries or
generated code in groovy, that is not following the conventions can be worked
around. Groovy supports import aliases. Thus you can do "import
com.generated.something.foo as Foo" and if you then do "def foo = Foo" it will
resolve to the class com.generated.something.foo. This alias can be used
anywhere, also in implements or extends.
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the
[jira] [Assigned] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-11222:
-
Assignee: Jochen Theodorou
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the parser work in the same way as expected after reading
> the language spec. I am not sure, however, whether this won't break anything
> else.
> In order to avoid any unnecessary discussions about naming conventions: I am
> aware that by convention it is not OK to start a type name with anything
> other than a capital letter, but there are valid cases where it is desired to
> have such names (e.g. generated code based on external input, DSLs).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-8254.
-
Fix Version/s: 5.0.0-alpha-3
Resolution: Fixed
https://github.com/apache/groovy/commit/b90b015659aa6d6eb233b7f9e7bfa8add36ded43
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
> Fix For: 5.0.0-alpha-3
>
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786011#comment-17786011
]
Eric Milles commented on GROOVY-8254:
-
There should probably be an error or warning for having an alias and a local
type with the same name -- at least in the default package where there is no
qualifier available.
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8254:
Labels: breaking breaking_change (was: )
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, breaking_change
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785957#comment-17785957
]
Eric Milles commented on GROOVY-8254:
-
In order to change the precedence of alias vs. same-source-unit type,
{{ResolveVisitor#resolveFromModule}} would need to move call to
{{resolveAliasFromModule}} up above the loop to check local names.
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785932#comment-17785932
]
Eric Milles commented on GROOVY-8254:
-
Both resolve to locally-defined Bar at first. The anon. inner class passes
through ResolveVisitor again and at this time, "Bar -> Bar" is replaced with
"Foo".
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-8254) Alias is ignored in constructor call
[
https://issues.apache.org/jira/browse/GROOVY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8254:
---
Assignee: Eric Milles
> Alias is ignored in constructor call
>
>
> Key: GROOVY-8254
> URL: https://issues.apache.org/jira/browse/GROOVY-8254
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>
> {code:title=foo/Foo.groovy}
> package foo
> class Foo {}
> {code}
> {code:title=test/test.groovy}
> package test
> import foo.Foo as Bar
> class Bar {}
> def regular = new Bar()
> def anonymous = new Bar() {}
> println regular.class // class test.Bar
> println anonymous.class.superclass // class foo.Foo
> {code}
> Either both of the invocations should use alias or both of them should use
> class defined in the same file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-8645) ClassCastException after checking of instanceOf
[
https://issues.apache.org/jira/browse/GROOVY-8645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles closed GROOVY-8645.
---
Resolution: Information Provided
> ClassCastException after checking of instanceOf
> ---
>
> Key: GROOVY-8645
> URL: https://issues.apache.org/jira/browse/GROOVY-8645
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.11
>Reporter: Aram Arabyan
>Priority: Minor
>
> Have grails (version 3.2.11) application (it includes groovy-2.4.11.jar).
> And following code
> {code:groovy}
> @CompileStatic
> def removeAllErrors(DomainClass domainInstance) {
> newAssociationOperationRunnerBuilder(domainInstance)
> .setSkipChain({DomainObjectDetails
> domainObjectDetails ->
> skipValidation(domainObjectDetails.currentDomain.domainObject,
> domainObjectDetails.associationProp?.name)})
> .build().run({DomainObjectDetails
> domainObjectDetails ->
> DomainClass domain =
> domainObjectDetails.currentDomain.domainObject
> if (domain instanceof GormValidateable) {
> ((GormValidateable)domain).clearErrors()
> }
> if(domain instanceof WarningsHolder) {
> WarningsHolder warningsHolder = domain as WarningsHolder
> //<--line 120
> Warnings warnings = warningsHolder.getWarnings()
> warnings.clearWarnings(false, true)
> }
> })
> }
> {code}
> And I am getting following exception
> {code}
> java.lang.IllegalArgumentException: java.lang.ClassCastException@58798bfb
> at sun.reflect.GeneratedMethodAccessor5958.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
> at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1125)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:925)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:908)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:168)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.asType(ScriptBytecodeAdapter.java:591)
> at
> com.webbfontaine.grails.plugins.validation.rules.DocVerificationService$_removeAllErrors_closure5.doCall(DocVerificationService.groovy:120)
> at sun.reflect.GeneratedMethodAccessor2559.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325){code}
> Any idea what can be the reason ? Pay attention that I have @CompileStatic
> there also.
> =
> Previous version of this code was without @CompileStatic
> {code:groovy}
> def removeAllErrors(def domainInstance) {
> newAssociationOperationRunnerBuilder(domainInstance)
> .setSkipChain({DomainObjectDetails
> domainObjectDetails ->
> skipValidation(domainObjectDetails.currentDomain.domainObject,
> domainObjectDetails.associationProp?.name)})
> .build().run({DomainObjectDetails
> domainObjectDetails ->
> domainObjectDetails.currentDomain.domainObject.clearErrors()
> if(domainObjectDetails.currentDomain.domainObject instanceof
> WarningsHolder) {
> Warnings warnings =
> domainObjectDetails.currentDomain.domainObject.getWarnings()
> warnings.clearWarnings(false, true)
> }
> })
> }
> {code}
> And I was getting this exception
> {code}
> com.webbfontaine.sw.sad.ci.Item cannot be cast to
> com.webbfontaine.sw.sad.ci.Item_$$_jvst840_3. Stacktrace follows:
> java.lang.ClassCastException: com.webbfontaine.sw.sad.ci.Item cannot be cast
> to com.webbfontaine.sw.sad.ci.Item_$$_jvst840_3 at
> com.webbfontaine.grails.plugins.validation.rules.DocVerificationService$_removeAllErrors_closure5.doCall(DocVerificationService.groovy:111){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-8028) @CompileStatic causes behavioral change in how interfaces work
[
https://issues.apache.org/jira/browse/GROOVY-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles closed GROOVY-8028.
---
Resolution: Not A Bug
> @CompileStatic causes behavioral change in how interfaces work
> --
>
> Key: GROOVY-8028
> URL: https://issues.apache.org/jira/browse/GROOVY-8028
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.4
> Environment: Windows / Grails 2.5.4
>Reporter: Chris Erickson
>Priority: Major
>
> Given an interface:
> {code}
> interface SomeInterface {
> String name
> }
> {code}
> and a class:
> {code}
> class SomeClass implements SomeInterface {
> String name
> }
> {code}
> and a wrapper class, for which we have a statically compiled and
> non-statically compiled version:
> {code}
> class WrapperClass {
> SomeInterface delegate
> String getName() { delegate.name }
> }
> @CompileStatic
> class StaticCompileWrapperClass {
> SomeInterface delegate
> String getName() { delegate.name }
> }
> {code}
> The behavior of the two classes is different, with no compiler warnings or
> errors, as demonstrated by this script:
> {code}
> def wrapped = new WrapperClass(delegate: new SomeClass(name: "Name"))
> assert wrapped.name == "Name" // ok
> assert wrapped.getName() == "Name" // ok
> def wrapped2 = new StaticCompileWrapperClass(delegate: new
> SomeClass(name: "Name"))
> assert wrapped2.name == "Name" // fail
> assert wrapped2.getName() == "Name" // fail
> {code}
> It was pointed out when I reported this to grails (I thought it was a
> @GrailsCompileStatic issue but it turns out I had defined it differently in
> my interface) that the interface definition is incorrect (I'd assumed you
> could define a property on an interface, which would imply the
> getters/setters) and that leads to the issue.
> However, I think that the functional behavior of a class should not change
> based on a @CompileStatic annotation. Minimally, if it does change, there
> should be compiler warnings or errors. The fix may be that the compiler
> should fail saying that "SomeClass" doesn't implement the interface, or that
> when it isn't compiled static it also returns null. I could be convinced
> either way, the inconsistency is my complaint.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
