[GitHub] [groovy] asfgit closed pull request #1538: GROOVY-9993: clarify boundary cases for split property definition (field and property of same name)
asfgit closed pull request #1538: URL: https://github.com/apache/groovy/pull/1538 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-10004) @Lazy transform should check for explicit getters/setters
[
https://issues.apache.org/jira/browse/GROOVY-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-10004.
Fix Version/s: 4.0.0-alpha-3
Resolution: Fixed
Proposed PR merged. Currently synthetic accessor methods are ignored if found.
This is an escape clause which leaves wiggle room for AST transforms at the
risk of a poorer error message if an AST transform does the wrong thing -
either some kind of Groovy warning about duplication or in the worst case, a VM
class error. The escape clause was currently needed for @Field. We could
consider weakening or removing the escape clause down the track:
* A more liberal escape clause would be to also ignore @Generated accessor
methods if found, something to keep in mind if other frameworks end up being
affected
* We could remove the escape clause if we rework @Field but maybe other
frameworks would also be impacted and need this wiggle room anyway
> @Lazy transform should check for explicit getters/setters
> -
>
> Key: GROOVY-10004
> URL: https://issues.apache.org/jira/browse/GROOVY-10004
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
> Fix For: 4.0.0-alpha-3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{@Lazy}} transform renames the backing field to "make it more hidden"
> and doesn't provide a setter, hence making the field read-only (apart from
> reflection tricks).
> {code}
> class Zoo {
> @Lazy String animal = { 'sloth' }()
> //void setAnimal(String animal) { this.animal = animal }
> //String getAnimal() { this.animal }
> }
> {code}
> Here {{animal}} becomes {{$animal}}. The intention is to disallow the fields
> use anymore apart from the sanctioned initialization code provided by the
> transform. No attempt is made to rename usages of the field that may
> otherwise occur within the class. Hence adding an explicit getter or setter
> in the normal way yields a {{StackOverflowError}} when trying to access the
> original property or {{MissingFieldException}} if trying to access the field
> directly, i.e. {{this.@animal}}. The transform should instead issue an error
> if explicit getters/setters are found. It would still be possible to access
> the {{$animal}} field (which in general may or may not be initialized) if
> there was really a need, just not in the standard getter or setter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] paulk-asert commented on pull request #1537: GROOVY-10004: @Lazy transform should check for explicit getters/setters
paulk-asert commented on pull request #1537: URL: https://github.com/apache/groovy/pull/1537#issuecomment-811506583 Proposed PR merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] asfgit closed pull request #1537: GROOVY-10004: @Lazy transform should check for explicit getters/setters
asfgit closed pull request #1537: URL: https://github.com/apache/groovy/pull/1537 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert commented on pull request #1540: Fix typo in metaprogramming documentation
paulk-asert commented on pull request #1540: URL: https://github.com/apache/groovy/pull/1540#issuecomment-811505035 Merged, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert merged pull request #1540: Fix typo in metaprogramming documentation
paulk-asert merged pull request #1540: URL: https://github.com/apache/groovy/pull/1540 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-9033) Bad code green: empty list literal with each method
[
https://issues.apache.org/jira/browse/GROOVY-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312724#comment-17312724
]
Daniil Ovchinnikov commented on GROOVY-9033:
{code:groovy}
@groovy.transform.CompileStatic
List usage() {
def l = [].each {}
l.add(new Object())
return l
}
{code}
> Bad code green: empty list literal with each method
> ---
>
> Key: GROOVY-9033
> URL: https://issues.apache.org/jira/browse/GROOVY-9033
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.6
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:groovy}
> @groovy.transform.CompileStatic
> List usage() {
> def l = [].each {}
> return l // expected error: Incompatible generic argument types. Cannot
> assign java.util.List to: java.util.List
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] AnEmortalKid opened a new pull request #1540: Fix typo in metaprogramming documentation
AnEmortalKid opened a new pull request #1540: URL: https://github.com/apache/groovy/pull/1540 Fix a typoh -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GROOVY-10007) Breaking change in property resolution 2.4 -> 3.0
Jochen Eddelbuettel created GROOVY-10007:
Summary: Breaking change in property resolution 2.4 -> 3.0
Key: GROOVY-10007
URL: https://issues.apache.org/jira/browse/GROOVY-10007
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 3.0.7, 3.0.5
Environment: OpenJDK 11, IdeaC 2020.3.3
Reporter: Jochen Eddelbuettel
I've created a library utilizing propertyMissing. By convention, it expects
property names to be running against camel casing conventions (starting with a
single upper case letter), to avoid conflicts with actual properties (bean
style, with getters).
In Groovy 2.4 a call of obj.Owner would not be resolved to obj.getOwner(). Only
obj.owner would be equivalent to obj.getOwner(). In Groovy 3.0 obj.Owner
results in a call to obj.getOwner() as well. As a result, no call to
propertyMissing for "Owner" occurs any more. Thus properties that used to be
resolved by metaprogramming, can now result in actual method calls, which can
potentially have a huge impact on the behavior of existing code.
I've looked back into the 3.0.0 release notes and there is no mention of this
being a breaking change.
This script, who assertions were jolly fine in 2.4.15, should behave the same
in 3.0.x:
{code:java}
import groovy.json.JsonSlurper
JsonSlurper.metaClass.propertyMissing = { String name -> name }
def slurp = new JsonSlurper()
slurp.maxSizeForInMemory = 50
assert slurp.maxSizeForInMemory == 50
assert slurp.MaxSizeForInMemory == "MaxSizeForInMemory"
{code}
Interestingly, this is not a problem for setters, which suggests to me that the
change is unintended behaviour get getters and should be fixed. It is a problem
with @CompileStatic too. obj.Owner statically compiles to obj.getOwner().
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10006) @CompileStatic fails to unify types
Konstantin Nisht created GROOVY-10006:
-
Summary: @CompileStatic fails to unify types
Key: GROOVY-10006
URL: https://issues.apache.org/jira/browse/GROOVY-10006
Project: Groovy
Issue Type: Bug
Components: Static compilation, Static Type Checker
Affects Versions: 3.0.6
Reporter: Konstantin Nisht
{code:groovy}
@CompileStatic
class A {
static void foo(U a, U b) {}
static void main(String[] args) {
foo(1, "")
}
}
{code}
The following code fails to compile with error
{{Groovyc: [Static type checking] - Cannot call A#foo(U, U) with arguments
[int, java.lang.String]}}
{{U}} should be inferred to LUB(Integer, String), hence the call should be
successful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-7978) Code containing post-decrement in an assert can cause a VerifyError on instantiation
[
https://issues.apache.org/jira/browse/GROOVY-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312382#comment-17312382
]
Eric Milles commented on GROOVY-7978:
-
I do not. I think the fix that popped the extra operand (GROOVY-9892) was the
one that did it.
> Code containing post-decrement in an assert can cause a VerifyError on
> instantiation
>
>
> Key: GROOVY-7978
> URL: https://issues.apache.org/jira/browse/GROOVY-7978
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5, 2.4.7
> Environment: Ubuntu 14.04.5 LTS (Trusty)
> Java: 1.8.0_91
> x86_64 arch (both OS and Java)
>Reporter: Nick Stokoe
>Assignee: Eric Milles
>Priority: Major
>
> The program below attempts to show a minimal example. It fails with a
> VerifyError when an instance of class Bad is constructed. Removing the
> post-increment or the assert, or making it @CompileStatic makes the error go
> away.
> {code}
> // VerifyErrorExample.groovy
> import groovy.transform.CompileStatic
> class Bad {
> private int counter = 0;
>
> void bar() {
> assert (this.counter++) // Something about the post-decrement
> in an assert causes a VerifyError
> }
> };
> @CompileStatic
> class Good {
> private int counter = 0;
>
> void bar() {
> assert (this.counter++) // This is fine
> }
> };
> println "Java: ${System.getProperty('java.version')}, Groovy:
> ${GroovySystem.version}"
> new Good();
> println "made a good"
> new Bad();
> println "made a bad"
> {code}
> The error looks like this:
> {code}
> $ groovy VerifyErrorExample.groovy
> Java: 1.8.0_91, Groovy: 2.4.7
> made a good
> Caught: java.lang.VerifyError: (class: Bad, method: bar signature: ()V)
> Expecting to find integer on stack
> java.lang.VerifyError: (class: Bad, method: bar signature: ()V) Expecting to
> find integer on stack
> at VerifyErrorExample.run(VerifyErrorExample.groovy:24)
> {code}
> I've seen other errors of a similar sort, which I've not been able to boil
> down to a short example like this, but one I can remember seemed to be the
> result of code which use a void method in an if-condition (which the compiler
> didn't warn about), something like this:
> {code}
> class Foo {
> public void voidMethod() {}
> public void bad() {
> if (voidMethod()) {
> prinln "hello"
> }
> }
> }
> new Foo(); // triggers the error
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] paulk-asert opened a new pull request #1539: GROOVY-10005: Remove groovy-jaxb module from Groovy 4
paulk-asert opened a new pull request #1539: URL: https://github.com/apache/groovy/pull/1539 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GROOVY-10005) Remove groovy-jaxb module from Groovy 4
Paul King created GROOVY-10005: -- Summary: Remove groovy-jaxb module from Groovy 4 Key: GROOVY-10005 URL: https://issues.apache.org/jira/browse/GROOVY-10005 Project: Groovy Issue Type: Task Reporter: Paul King Assignee: Paul King Groovy provides some minimal extension methods related to JAXB. Due to JDK9+ no longer bundling those classes, this support is problematical. Given the minimal value add of those methods and increased complexity, this task is to remove that functionality. See: https://lists.apache.org/thread.html/r2af467cc6967d3c21970241cdf79821a61619a49f416face95390d1b%40%3Cdev.groovy.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
