[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253005#comment-16253005
]
Paul King commented on GROOVY-8380:
---
Right, that's correct. Please ignore the assignment example difference between
static/dynamic above as dynamic Groovy has extra coercion going on of course.
So, to summarise, here is what used to happen:
{code}
Long wl = 1L
long pl = 1L
assert new Integer(wl & wl) > 0 // GRE when dynamic, STC incorrectly passes
assert new Long(wl & wl) > 0 //
assert new Integer(pl & pl) > 0 // GRE when dynamic, STC detects
assert new Long(pl & pl) > 0 //
assert new Long(6 & 3) == 2L //
assert new Long(-2 & 3) == 2L//
{code}
Here is what happens now:
{code}
Long wl = 1L
long pl = 1L
assert new Integer(wl & wl) > 0 // GRE, STC detects
assert new Long(wl & wl) > 0 // STC incorrectly fails
assert new Integer(pl & pl) > 0 // GRE, STC detects
assert new Long(pl & pl) > 0 //
assert new Long(6 & 3) == 2L //
assert new Long(-2 & 3) == 2L// STC incorrectly fails
{code}
Fixing the GROOVY-8325 bug has revealed another.
The type for x & y is being correctly determined for primitives
({{WideningCategories.isIntCategory}}) but fails for wrappers. 6 is given type
int, -2 is given type Integer, so it also fails.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252863#comment-16252863
]
Jochen Theodorou commented on GROOVY-8380:
--
Please bear in mind, that an assignment in dynamic Groovy is no substitute for
a method parameter. In Groovy the assignment involves an implicit cast, that is
not the case for a method call. So it is always legal to assign a number typed
value to a variable with another number type, even if that means a loss of
precision. As for what types are compatible with a Long/long typed parameter
you should take a look at LongCachedClass#isAssignableFrom.You will see there,
that Double, Float and BigDecimal are no candidates. And if you then look at
DoubleCachedClass and FloatCachedClass, you will that loss of precision is
really no factor here. In fact if you look at IntegerCachedClass you will see
that it is perfectly legal to pass an BigInteger or Long for an int parameter.
What we did not do in dynamic Groovy is allow floating points typed arguments
for integer types parameters. Why that is... frankly I have no idea.That goes
back to March 2008 at least. But I don´t think that was a change, since even
groovy-beta-9 fails to call a method with a long parameter using a BigDecimal
argument.
Static Groovy has the "no loss of precision" rule, thus here it should be even
more clear what is required.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252686#comment-16252686
]
Paul King edited comment on GROOVY-8380 at 11/15/17 1:57 AM:
-
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but these are okay:
{code}
Integer x = 1 & 3
new Long(6 & 3)
{code}
and this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. And for whatever reason,
constant 3 is given type {{int}} but constant -1 is given type {{Integer}}. We
don't do that for other operators like + and *, so there is room for
improvement there.
was (Author: paulk):
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but these are okay:
{code}
Integer x = 1 & 3
new Long(7 ^ 3)
{code}
and this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. And for whatever reason,
constant 3 is given type {{int}} but constant -1 is given type {{Integer}}. We
don't do that for other operators like + and *, so there is room for
improvement there.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252686#comment-16252686
]
Paul King edited comment on GROOVY-8380 at 11/15/17 1:56 AM:
-
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but these are okay:
{code}
Integer x = 1 & 3
new Long(7 ^ 3)
{code}
and this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. And for whatever reason,
constant 3 is given type {{int}} but constant -1 is given type {{Integer}}. We
don't do that for other operators like + and *, so there is room for
improvement there.
was (Author: paulk):
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but this is okay:
{code}
Integer x = 1 & 3
{code}
and this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. And for whatever reason,
constant 3 is given type {{int}} but constant -1 is given type {{Integer}}. We
don't do that for other operators like + and *, so there is room for
improvement there.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252686#comment-16252686
]
Paul King edited comment on GROOVY-8380 at 11/15/17 1:53 AM:
-
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but this is okay:
{code}
Integer x = 1 & 3
{code}
and this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. And for whatever reason,
constant 3 is given type {{int}} but constant -1 is given type {{Integer}}. We
don't do that for other operators like + and *, so there is room for
improvement there.
was (Author: paulk):
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. We don't do that for
other operators like + and *, so there is room for improvement there.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252686#comment-16252686
]
Paul King commented on GROOVY-8380:
---
That does look wrong but unrelated. It matches what this gives:
{code}
Integer x = -1 & 3
{code}
but this is okay:
{code}
int a = -1
int b = 3
int c = a & b
{code}
It seems that we match on {{NumberMathModificationInfo#or}} for primitives but
fall back to the {{Number}} variant for wrapper types. We don't do that for
other operators like + and *, so there is room for improvement there.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252621#comment-16252621
]
Patric Bechtel commented on GROOVY-8380:
How about {code}new Integer( 3 & (-1 ^ 3) ){code}?
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252522#comment-16252522
]
Paul King edited comment on GROOVY-8380 at 11/14/17 10:19 PM:
--
It's not clear to me if this is a bug though perhaps the fix in GROOVY-8325
could have been done in 2.5+. From looking at the changed code, it was always
the intention to fail the match due to loss of precision but a missing
{{redirect()}} meant that it was incorrectly passed for quite some time.
Dynamic Groovy does not match that constructor in 2.4.12 due to possible loss
of precision (and I tried numerous versions back to 1.8.9 with the same result):
{noformat}
groovy.lang.GroovyRuntimeException:
Could not find matching constructor for: java.lang.Long(java.math.BigDecimal)
{noformat}
Perhaps we need an error message indicating possible loss of precision as the
cause.
Static Groovy also rejects: {{Long foo = 5 / 3}} but dynamic Groovy accepts
this.
Anyway, let's see what others think.
was (Author: paulk):
It's not clear to me if this is a bug.
Dynamic Groovy does not match that constructor in 2.4.12 due to possible loss
of precision (and I tried numerous versions back to 1.8.9 with the same result):
{noformat}
groovy.lang.GroovyRuntimeException:
Could not find matching constructor for: java.lang.Long(java.math.BigDecimal)
{noformat}
Perhaps we need an error message indicating possible loss of precision as the
cause.
Static Groovy also rejects: {{Long foo = 5 / 3}} but dynamic Groovy accepts
this.
Anyway, let's see what others think.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252522#comment-16252522
]
Paul King commented on GROOVY-8380:
---
It's not clear to me if this is a bug.
Dynamic Groovy does not match that constructor in 2.4.12 due to possible loss
of precision (and I tried numerous versions back to 1.8.9 with the same result):
{noformat}
groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
java.lang.Long(java.math.BigDecimal)
{noformat}
Perhaps we need an error message indicating possible loss of precision as the
cause.
Static Groovy also rejects: {{Long foo = 5 / 3}} but dynamic Groovy accepts
this.
Anyway, let's see what others think.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252522#comment-16252522
]
Paul King edited comment on GROOVY-8380 at 11/14/17 10:02 PM:
--
It's not clear to me if this is a bug.
Dynamic Groovy does not match that constructor in 2.4.12 due to possible loss
of precision (and I tried numerous versions back to 1.8.9 with the same result):
{noformat}
groovy.lang.GroovyRuntimeException:
Could not find matching constructor for: java.lang.Long(java.math.BigDecimal)
{noformat}
Perhaps we need an error message indicating possible loss of precision as the
cause.
Static Groovy also rejects: {{Long foo = 5 / 3}} but dynamic Groovy accepts
this.
Anyway, let's see what others think.
was (Author: paulk):
It's not clear to me if this is a bug.
Dynamic Groovy does not match that constructor in 2.4.12 due to possible loss
of precision (and I tried numerous versions back to 1.8.9 with the same result):
{noformat}
groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
java.lang.Long(java.math.BigDecimal)
{noformat}
Perhaps we need an error message indicating possible loss of precision as the
cause.
Static Groovy also rejects: {{Long foo = 5 / 3}} but dynamic Groovy accepts
this.
Anyway, let's see what others think.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8380:
--
Description:
This used to work up to 2.4.12:
{code}
@groovy.transform.CompileStatic
class bla {
static void main(String[] args) {
println new Long( 5 / 3 )
}
}
{code}
starting with 2.4.13, it gives this error message:
{noformat}
bla.groovy: 4: [Static type checking] - Cannot find matching method
java.lang.Long#(java.math.BigDecimal). Please check if the declared type
is right and if the method exists.
@ line 4, column 15.
println new Long( 5 / 3 )
{noformat}
was:
This used to work up to 2.4.12:
@groovy.transform.CompileStatic
class bla {
static void main(String[] args) {
println new Long( 5 / 3 )
}
}
starting with 2.4.13, it gives this error message:
bla.groovy: 4: [Static type checking] - Cannot find matching method
java.lang.Long#(java.math.BigDecimal). Please check if the declared type
is right and if the method exists.
@ line 4, column 15.
println new Long( 5 / 3 )
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> {code}
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> {code}
> starting with 2.4.13, it gives this error message:
> {noformat}
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8381) Other Operators section of Groovy docs missing get/set dot operator
[
https://issues.apache.org/jira/browse/GROOVY-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252239#comment-16252239
]
Eric Milles commented on GROOVY-8381:
-
Also the table in section 1.2.10
(http://docs.groovy-lang.org/latest/html/documentation/#Operator-Overloading)
could mention '.' -> get/set as well.
> Other Operators section of Groovy docs missing get/set dot operator
> ---
>
> Key: GROOVY-8381
> URL: https://issues.apache.org/jira/browse/GROOVY-8381
> Project: Groovy
> Issue Type: Documentation
> Components: Documentation
>Reporter: Eric Milles
>Priority: Minor
>
> Section 1.2.8 (Other Operators:
> http://docs.groovy-lang.org/latest/html/documentation/#_other_operators)
> mentions the Call Operator (aka call method). But I do not see mention of
> the get(name) and set(name,value) methods that lead to a "dot" operator
> overload as it is mentioned in Groovy in Action.
> Example (Call and Dot operator overloads):
> {code}
> class General {
> def call(... args) {
> println "Called with args: $args"
> }
> def get(String name) {
> println "Getting property: $name"
> }
> void set(String name, Object value) {
> println "Setting property: $name"
> }
> }
> General g = new General()
> g.unknown
> g.unknown = ''
> g("1", "2")
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-6453) groovysh in Windows 7/8/10 doesn't support arrow keys and Del
[
https://issues.apache.org/jira/browse/GROOVY-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252235#comment-16252235
]
Dariusz Antoniuk commented on GROOVY-6453:
--
You can add the following code to your groovy.rc as a workaround:
{noformat}
@groovy.transform.InheritConstructors
class WindowsTerminalControlCharFix extends jline.WindowsTerminal {
@Override
protected boolean isSystemIn(java.io.InputStream i) throws IOException {
// groovysh wraps the input stream in
WrappedInputStream, need to handle this case properly to enable windows
controll character handling
if (i instanceof
org.codehaus.groovy.tools.shell.util.WrappedInputStream) {
return
super.isSystemIn(((org.codehaus.groovy.tools.shell.util.WrappedInputStream)i).wrapped);
}
return super.isSystemIn(i);
}
}
// if no terminal specified use a version of windows terminal class that
handles windows control characters properly - see
https://issues.apache.org/jira/browse/GROOVY-6453
if (!System.getProperty("jline.terminal")) {
jline.TerminalFactory.registerFlavor(jline.TerminalFactory.Flavor.WINDOWS,
WindowsTerminalControlCharFix.class);
System.setProperty("jline.terminal","win");
}
{noformat}
> groovysh in Windows 7/8/10 doesn't support arrow keys and Del
> -
>
> Key: GROOVY-6453
> URL: https://issues.apache.org/jira/browse/GROOVY-6453
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.2.0
> Environment: Windows 8, 64bit (v6.2, build 9200), java version
> "1.7.0_45" SE Runtime Environment (build 1.7.0_45-b18) HotSpot 64-Bit Server
> VM (build 24.45-b08, mixed mode), Russian locale (!)
>Reporter: Andrew P Fink
> Labels: console, jline
>
> I have bare windows 8 with fresh JDK. I run Groovysh in cmd.exe.
> Groovysh 2.1.9 works as expected.
> Groovysh 2.2.0 doesn't react to arrow keys and Del, i.e. up key doesn't show
> previous command, left key doesn't shift cursor etc.
> After some investigation I found what is working:
> ctrl-a go to beginning of line
> ctrl-e go to End of line
> ctrl-f go Forward one char
> ctrl-b go Backward one char
> ctrl-d delete the char
> ctrl-h and backspace = delete left char
> ctrl-p recall previous line
> ctrl-n recall next line
> ctrl-s search
> ctrl-r reverse search
> It's nice and feel myself like a Linux hacker, but I want arrow keys too ;-)
> I tried different options:
> - upgrade jline2.10 to 2.11 - no effect
> - --terminal=unix - it helps, but duplicate prompt (groovy:000>) and no more
> colors in console
> Looks like problem lies in new jline v2 (groovysh 2.1.9 uses jline1.0)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8381) Other Operators section of Groovy docs missing get/set dot operator
Eric Milles created GROOVY-8381:
---
Summary: Other Operators section of Groovy docs missing get/set
dot operator
Key: GROOVY-8381
URL: https://issues.apache.org/jira/browse/GROOVY-8381
Project: Groovy
Issue Type: Documentation
Components: Documentation
Reporter: Eric Milles
Priority: Minor
Section 1.2.8 (Other Operators:
http://docs.groovy-lang.org/latest/html/documentation/#_other_operators)
mentions the Call Operator (aka call method). But I do not see mention of the
get(name) and set(name,value) methods that lead to a "dot" operator overload as
it is mentioned in Groovy in Action.
Example (Call and Dot operator overloads):
{code}
class General {
def call(... args) {
println "Called with args: $args"
}
def get(String name) {
println "Getting property: $name"
}
void set(String name, Object value) {
println "Setting property: $name"
}
}
General g = new General()
g.unknown
g.unknown = ''
g("1", "2")
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16251745#comment-16251745
]
Daniil Ovchinnikov commented on GROOVY-8254:
AFAIU there are no differences in how aliased/regular imports are treated by
compiler.
I.e. in case of
{code}
import test.Bar
import foo.Foo as Bar
{code}
the second import will overwrite the first one and vice versa, because
essentially these imports are both _aliased_:
{code}
import test.Bar as Bar
import foo.Foo as Bar
{code}
I suppose anonymous class references should obey the same rules as reference in
new expression, i.e. prefer a class in the same file over any import.
> 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
>
> {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
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8325) @CompileStatic calls wrong newInstance method.
[
https://issues.apache.org/jira/browse/GROOVY-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251506#comment-16251506
]
Patric Bechtel commented on GROOVY-8325:
Please have a look at GROOVY-8380, as this fix causes a regression for
@groovy.transform.CompileStatic
def bla() {
new Long( 5 / 2 )
}
That used to work and seems on par with the Java behaviour on that matter.
> @CompileStatic calls wrong newInstance method.
> --
>
> Key: GROOVY-8325
> URL: https://issues.apache.org/jira/browse/GROOVY-8325
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation
>Affects Versions: 2.4.10
>Reporter: Xiaoguang WANG
>Assignee: Paul King
>Priority: Critical
> Fix For: 2.4.13
>
>
> {code:java}
> import groovy.transform.CompileStatic
> class Foo {
> static Foo newInstance(Long v) {
> return new Foo()
> }
> }
> @CompileStatic //crash only caused by this CompileStatic
> class TestGroovy {
> static void main(String ... args) {
> def a = Foo.newInstance(123) //when @CompileStatic, this calls
> DefaultGroovyMethods.newInstance
> println a
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
[
https://issues.apache.org/jira/browse/GROOVY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251490#comment-16251490
]
Patric Bechtel commented on GROOVY-8380:
The reason seems to be the fix for GROOVY-8325.
> Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
>
>
> Key: GROOVY-8380
> URL: https://issues.apache.org/jira/browse/GROOVY-8380
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
> Environment: any
>Reporter: Patric Bechtel
>Priority: Critical
>
> This used to work up to 2.4.12:
> @groovy.transform.CompileStatic
> class bla {
>static void main(String[] args) {
> println new Long( 5 / 3 )
>}
> }
> starting with 2.4.13, it gives this error message:
> bla.groovy: 4: [Static type checking] - Cannot find matching method
> java.lang.Long#(java.math.BigDecimal). Please check if the declared
> type is right and if the method exists.
> @ line 4, column 15.
> println new Long( 5 / 3 )
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8380) Regression in 2.4.13 (snapshot) 62615249161b233b1827d5950671d3a83007cd9f
Patric Bechtel created GROOVY-8380:
--
Summary: Regression in 2.4.13 (snapshot)
62615249161b233b1827d5950671d3a83007cd9f
Key: GROOVY-8380
URL: https://issues.apache.org/jira/browse/GROOVY-8380
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 2.4.13
Environment: any
Reporter: Patric Bechtel
Priority: Critical
This used to work up to 2.4.12:
@groovy.transform.CompileStatic
class bla {
static void main(String[] args) {
println new Long( 5 / 3 )
}
}
starting with 2.4.13, it gives this error message:
bla.groovy: 4: [Static type checking] - Cannot find matching method
java.lang.Long#(java.math.BigDecimal). Please check if the declared type
is right and if the method exists.
@ line 4, column 15.
println new Long( 5 / 3 )
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8255) Odd problems with flow typing and generics in Groovy 2.4.12+
[
https://issues.apache.org/jira/browse/GROOVY-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8255.
---
Resolution: Fixed
Fix Version/s: 2.4.13
Proposed PR applied.
> Odd problems with flow typing and generics in Groovy 2.4.12+
>
>
> Key: GROOVY-8255
> URL: https://issues.apache.org/jira/browse/GROOVY-8255
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.12
>Reporter: Graeme Rocher
>Assignee: Paul King
> Fix For: 2.4.13
>
>
> In order to get the GORM codebase to compile I had to make this change:
> https://github.com/grails/grails-data-mapping/commit/1ef850c496d13d8ca915b27e76b6bfdb4e27377e
> The code in question is:
> {code}
> /**
> * Sets multipart values within the request body
> *
> * @param name The name of the multipart
> * @param value The value of the multipart
> */
> void setProperty(String name, value) {
> if (value instanceof File) {
> value = new FileSystemResource(value)
> }
> else if (value instanceof URL) {
> value = new UrlResource(value)
> }
> else if (value instanceof InputStream) {
> value = new InputStreamResource(value)
> }
> else if (value instanceof GString) {
> value = value.toString()
> }
> if( mvm[name] ) {
> mvm[name].add value
> }
> else {
> mvm.put(name, [value]) // <--- FAILS COMPILATION HERE
> }
> }
> {code}
> No matter what I tried I could not get it into to compile. The method accepts
> `put(String, List)` but fails compilation with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 392, column 13.
>mvm.put(name, [value])
>^
> {code}
> Altering the code to:
> {code}
>List values = [value]
>mvm.put(name, values)
> {code}
> Fails with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.List to:
> java.util.List
> @ line 392, column 35.
>List values = [value]
> ^
> RequestCustomizer.groovy: 393: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 393, column 13.
>mvm.put(name, values)
>^
> 2 errors
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8255) Odd problems with flow typing and generics in Groovy 2.4.12+
[
https://issues.apache.org/jira/browse/GROOVY-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251302#comment-16251302
]
ASF GitHub Bot commented on GROOVY-8255:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/635
> Odd problems with flow typing and generics in Groovy 2.4.12+
>
>
> Key: GROOVY-8255
> URL: https://issues.apache.org/jira/browse/GROOVY-8255
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.12
>Reporter: Graeme Rocher
>Assignee: Paul King
>
> In order to get the GORM codebase to compile I had to make this change:
> https://github.com/grails/grails-data-mapping/commit/1ef850c496d13d8ca915b27e76b6bfdb4e27377e
> The code in question is:
> {code}
> /**
> * Sets multipart values within the request body
> *
> * @param name The name of the multipart
> * @param value The value of the multipart
> */
> void setProperty(String name, value) {
> if (value instanceof File) {
> value = new FileSystemResource(value)
> }
> else if (value instanceof URL) {
> value = new UrlResource(value)
> }
> else if (value instanceof InputStream) {
> value = new InputStreamResource(value)
> }
> else if (value instanceof GString) {
> value = value.toString()
> }
> if( mvm[name] ) {
> mvm[name].add value
> }
> else {
> mvm.put(name, [value]) // <--- FAILS COMPILATION HERE
> }
> }
> {code}
> No matter what I tried I could not get it into to compile. The method accepts
> `put(String, List)` but fails compilation with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 392, column 13.
>mvm.put(name, [value])
>^
> {code}
> Altering the code to:
> {code}
>List values = [value]
>mvm.put(name, values)
> {code}
> Fails with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.List to:
> java.util.List
> @ line 392, column 35.
>List values = [value]
> ^
> RequestCustomizer.groovy: 393: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 393, column 13.
>mvm.put(name, values)
>^
> 2 errors
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #635: GROOVY-8255: Odd problems with flow typing and gen...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/635 ---
[jira] [Commented] (GROOVY-8255) Odd problems with flow typing and generics in Groovy 2.4.12+
[
https://issues.apache.org/jira/browse/GROOVY-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251237#comment-16251237
]
ASF GitHub Bot commented on GROOVY-8255:
Github user melix commented on a diff in the pull request:
https://github.com/apache/groovy/pull/635#discussion_r150800145
--- Diff:
src/main/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java ---
@@ -3461,6 +3465,36 @@ public void visitTernaryExpression(final
TernaryExpression expression) {
popAssignmentTracking(oldTracker);
}
+// currently just for empty literals, not for e.g.
Collections.emptyList() at present
+/// it seems attractive to want to do this for more cases but perhaps
not all cases
+private ClassNode checkForTargetType(final Expression expr, final
ClassNode type) {
+if (typeCheckingContext.getEnclosingBinaryExpression() != null &&
isEmptyCollection(expr)) {
+int op =
typeCheckingContext.getEnclosingBinaryExpression().getOperation().getType();
+if (isAssignment(op)) {
+VariableExpression target = (VariableExpression)
typeCheckingContext.getEnclosingBinaryExpression().getLeftExpression();
+return adjustForTargetType(target.getType(), type);
+}
+}
+return type;
+}
+
+private ClassNode adjustForTargetType(final ClassNode targetType,
final ClassNode resultType) {
+if (targetType.isUsingGenerics() &&
missesGenericsTypes(resultType)) {
+// unchecked assignment within ternary/elvis
+// examples:
+// List list = existingAs ?: []
+// in that case, the inferred type of the RHS is the type of
the RHS
+// "completed" with generics type information available in the
LHS
+return GenericsUtils.parameterizeType(targetType,
resultType.getPlainNodeReference());
+}
+return resultType;
+}
+
+private boolean isEmptyCollection(Expression expr) {
--- End diff --
Could be static.
> Odd problems with flow typing and generics in Groovy 2.4.12+
>
>
> Key: GROOVY-8255
> URL: https://issues.apache.org/jira/browse/GROOVY-8255
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.12
>Reporter: Graeme Rocher
>Assignee: Paul King
>
> In order to get the GORM codebase to compile I had to make this change:
> https://github.com/grails/grails-data-mapping/commit/1ef850c496d13d8ca915b27e76b6bfdb4e27377e
> The code in question is:
> {code}
> /**
> * Sets multipart values within the request body
> *
> * @param name The name of the multipart
> * @param value The value of the multipart
> */
> void setProperty(String name, value) {
> if (value instanceof File) {
> value = new FileSystemResource(value)
> }
> else if (value instanceof URL) {
> value = new UrlResource(value)
> }
> else if (value instanceof InputStream) {
> value = new InputStreamResource(value)
> }
> else if (value instanceof GString) {
> value = value.toString()
> }
> if( mvm[name] ) {
> mvm[name].add value
> }
> else {
> mvm.put(name, [value]) // <--- FAILS COMPILATION HERE
> }
> }
> {code}
> No matter what I tried I could not get it into to compile. The method accepts
> `put(String, List)` but fails compilation with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 392, column 13.
>mvm.put(name, [value])
>^
> {code}
> Altering the code to:
> {code}
>List values = [value]
>mvm.put(name, values)
> {code}
> Fails with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.List to:
> java.util.List
> @ line 392, column 35.
>List values = [value]
> ^
> RequestCustomizer.groovy: 393: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 393, column 13.
>mvm.put(name, values)
>^
> 2 errors
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #635: GROOVY-8255: Odd problems with flow typing and gen...
Github user melix commented on a diff in the pull request:
https://github.com/apache/groovy/pull/635#discussion_r150800145
--- Diff:
src/main/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java ---
@@ -3461,6 +3465,36 @@ public void visitTernaryExpression(final
TernaryExpression expression) {
popAssignmentTracking(oldTracker);
}
+// currently just for empty literals, not for e.g.
Collections.emptyList() at present
+/// it seems attractive to want to do this for more cases but perhaps
not all cases
+private ClassNode checkForTargetType(final Expression expr, final
ClassNode type) {
+if (typeCheckingContext.getEnclosingBinaryExpression() != null &&
isEmptyCollection(expr)) {
+int op =
typeCheckingContext.getEnclosingBinaryExpression().getOperation().getType();
+if (isAssignment(op)) {
+VariableExpression target = (VariableExpression)
typeCheckingContext.getEnclosingBinaryExpression().getLeftExpression();
+return adjustForTargetType(target.getType(), type);
+}
+}
+return type;
+}
+
+private ClassNode adjustForTargetType(final ClassNode targetType,
final ClassNode resultType) {
+if (targetType.isUsingGenerics() &&
missesGenericsTypes(resultType)) {
+// unchecked assignment within ternary/elvis
+// examples:
+// List list = existingAs ?: []
+// in that case, the inferred type of the RHS is the type of
the RHS
+// "completed" with generics type information available in the
LHS
+return GenericsUtils.parameterizeType(targetType,
resultType.getPlainNodeReference());
+}
+return resultType;
+}
+
+private boolean isEmptyCollection(Expression expr) {
--- End diff --
Could be static.
---
