[jira] [Created] (GROOVY-10064) STC infers incorrect type for closure parameter
Christopher Smith created GROOVY-10064:
--
Summary: STC infers incorrect type for closure parameter
Key: GROOVY-10064
URL: https://issues.apache.org/jira/browse/GROOVY-10064
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 3.0.8
Reporter: Christopher Smith
I have this subroutine in some code managing DynamoDB tables; the types are
from the Amazon 2 SDK and Vavr. The {{Either#fold}} method takes a {{Function}} and a {{Function}} (collapsing
either a "left" or a "right" value into a single result). In this particular
case, both types are the same {{DynamoDbTable}}, just representing different
process states. The result type is a {{Try}}.
Aside from needing the workarounds that I think are related to GROOVY-10033
({{.&}} and {{as CheckedRunnable}}), this code _works as expected_ in
GRECLIPSE, but it fails when compiled with groovyc.
{code:groovy}
private Try waitForTableActive(Either maybeActive) {
maybeActive.fold(
Try., // we already determined it's active
table -> {
log.debug('waiting for table {} to become active',
table.tableName())
Try.success(table)
.andThenTry({ poll.until { checkActive(table).isLeft() } }
as CheckedRunnable)
}
)
}
Either checkActive(DynamoDbTable table) {}
{code}
{code}
Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.10.0:compile
(default) on project azimuth-server: Error occurred while calling a method on a
Groovy class from classpath.: InvocationTargetException: startup failed:
DynamoDbSchemaRegistryImpl.groovy: 134: [Static type checking] - Cannot find
matching method io.vavr.control.Try#tableName(). Please check if the declared
type is correct and if the method exists.
@ line 134, column 68.
r table {} to become active', table.tabl
^
DynamoDbSchemaRegistryImpl.groovy: 136: [Static type checking] - Cannot find
matching method
co.vendorflow.azimuth.server.infrastructure.data.dynamodb.DynamoDbSchemaRegistryImpl#checkActive(io.vavr.control.Try
). Please check if the declared type is correct and if the method exists.
@ line 136, column 59.
Try({ poll.until { checkActive(table).is
^
DynamoDbSchemaRegistryImpl.groovy: 136: [Static type checking] - Cannot find
matching method java.lang.Object#isLeft(). Please check if the declared type is
correct and if the method exists.
@ line 136, column 48.
.andThenTry({ poll.until { checkActiv
^
DynamoDbSchemaRegistryImpl.groovy: 131: [Static type checking] - Cannot call
io.vavr.control.Either #fold(java.util.function.Function ,
java.util.function.Function ) with
arguments [groovy.lang.Closure , groovy.lang.Closure]
@ line 131, column 9.
maybeActive.fold(
^
{code}
I have absolutely no idea how the STC gets the idea that the _parameter_ of the
outer closure should be a {{Try}} (the _result_ should be), and it seems
possible that the rest of the errors are a cascade from that initial mistake.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10064) STC infers incorrect type for closure parameter
[
https://issues.apache.org/jira/browse/GROOVY-10064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Smith updated GROOVY-10064:
---
Description:
I have this subroutine in some code managing DynamoDB tables; the types are
from the Amazon 2 SDK and Vavr. The {{Either#fold}} method takes a {{Function}} and a {{Function}} (collapsing
either a "left" or a "right" value into a single result). In this particular
case, both types are the same {{DynamoDbTable}}, just representing different
process states. The result type is a {{Try}}.
Aside from needing the workarounds that I think are related to GROOVY-10033
({{.&}} and {{as CheckedRunnable}}), this code _works as expected_ in
GRECLIPSE, but it fails when compiled with groovyc.
{code:groovy}
private Try waitForTableActive(Either maybeActive) {
maybeActive.fold(
Try., // we already determined it's active
table -> {
log.debug('waiting for table {} to become active',
table.tableName())
Try.success(table)
.andThenTry({ poll.until { checkActive(table).isLeft() } }
as CheckedRunnable)
}
)
}
Either checkActive(DynamoDbTable table) {}
{code}
{code}
Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.10.0:compile
(default) on project azimuth-server: Error occurred while calling a method on a
Groovy class from classpath.: InvocationTargetException: startup failed:
DynamoDbSchemaRegistryImpl.groovy: 134: [Static type checking] - Cannot find
matching method io.vavr.control.Try#tableName(). Please check if the declared
type is correct and if the method exists.
@ line 134, column 68.
r table {} to become active', table.tabl
^
DynamoDbSchemaRegistryImpl.groovy: 136: [Static type checking] - Cannot find
matching method
co.vendorflow.azimuth.server.infrastructure.data.dynamodb.DynamoDbSchemaRegistryImpl#checkActive(io.vavr.control.Try
). Please check if the declared type is correct and if the method exists.
@ line 136, column 59.
Try({ poll.until { checkActive(table).is
^
DynamoDbSchemaRegistryImpl.groovy: 136: [Static type checking] - Cannot find
matching method java.lang.Object#isLeft(). Please check if the declared type is
correct and if the method exists.
@ line 136, column 48.
.andThenTry({ poll.until { checkActiv
^
DynamoDbSchemaRegistryImpl.groovy: 131: [Static type checking] - Cannot call
io.vavr.control.Either #fold(java.util.function.Function ,
java.util.function.Function ) with
arguments [groovy.lang.Closure , groovy.lang.Closure]
@ line 131, column 9.
maybeActive.fold(
^
{code}
I have absolutely no idea how the STC gets the idea that the _parameter_ of the
outer closure should be a {{Try}} (the _result_ should be), and it seems
possible that the rest of the errors are a cascade from that initial mistake.
Adding an explicit {{(DynamoDbTable table) ->}} gets groovyc to compile it, but
then I still need to say {{as Function}} everywhere or I get complaints that
"closure is not a function".
was:
I have this subroutine in some code managing DynamoDB tables; the types are
from the Amazon 2 SDK and Vavr. The {{Either#fold}} method takes a {{Function}} and a {{Function}} (collapsing
either a "left" or a "right" value into a single result). In this particular
case, both types are the same {{DynamoDbTable}}, just representing different
process states. The result type is a {{Try}}.
Aside from needing the workarounds that I think are related to GROOVY-10033
({{.&}} and {{as CheckedRunnable}}), this code _works as expected_ in
GRECLIPSE, but it fails when compiled with groovyc.
{code:groovy}
private Try waitForTableActive(Either maybeActive) {
maybeActive.fold(
Try., // we already determined it's active
table -> {
log.debug('waiting for table {} to become active',
table.tableName())
Try.success(table)
.andThenTry({ poll.until { checkActive(table).isLeft() } }
as CheckedRunnable)
}
)
}
Either checkActive(DynamoDbTable table) {}
{code}
{code}
Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.10.0:compile
(default) on project azimuth-server: Error occurred while calling a method on a
Groovy class from classpath.: InvocationTargetException: startup failed:
DynamoDbSchemaRegistryImpl.groovy: 134: [Static type checking] - Cannot find
matching method io.vavr.control.Try#tableName(). Please check if the declared
type is correct and if the method exists.
@ line 134, column 68.
r table {} to become active', table.tabl
^
DynamoDbSchemaRegistryImpl.groovy: 136: [Static type checking] - Cannot find
matching method
[jira] [Created] (GROOVY-10063) STC: multiple-assignment from tuple-bearing static method
Eric Milles created GROOVY-10063:
Summary: STC: multiple-assignment from tuple-bearing static method
Key: GROOVY-10063
URL: https://issues.apache.org/jira/browse/GROOVY-10063
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Eric Milles
Assignee: Eric Milles
Follow up from GROOVY-8223 and GROOVY-8887. Consider the following:
{code:groovy}
static Tuple2 make() {
Tuple.tuple('answer', 42)
}
@groovy.transform.CompileStatic
void test() {
// Fixed in Groovy 3? Backport to Groovy 2.5?
def (String string, Integer number) = make();
println string
println number
}
test()
{code}
Destructuring of tuple fails for static method call expression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10063) STC: multiple-assignment from tuple-bearing static method
[
https://issues.apache.org/jira/browse/GROOVY-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10063:
-
Description:
Follow up from GROOVY-8223 and GROOVY-8887. Consider the following:
{code:groovy}
static Tuple2 make() {
Tuple.tuple('answer', 42)
}
@groovy.transform.CompileStatic
void test() {
def (String string, Integer number) = make()
println string
println number
}
test()
{code}
Destructuring of tuple fails for static method call expression.
was:
Follow up from GROOVY-8223 and GROOVY-8887. Consider the following:
{code:groovy}
static Tuple2 make() {
Tuple.tuple('answer', 42)
}
@groovy.transform.CompileStatic
void test() {
// Fixed in Groovy 3? Backport to Groovy 2.5?
def (String string, Integer number) = make();
println string
println number
}
test()
{code}
Destructuring of tuple fails for static method call expression.
> STC: multiple-assignment from tuple-bearing static method
> -
>
> Key: GROOVY-10063
> URL: https://issues.apache.org/jira/browse/GROOVY-10063
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Follow up from GROOVY-8223 and GROOVY-8887. Consider the following:
> {code:groovy}
> static Tuple2 make() {
> Tuple.tuple('answer', 42)
> }
> @groovy.transform.CompileStatic
> void test() {
> def (String string, Integer number) = make()
> println string
> println number
> }
> test()
> {code}
> Destructuring of tuple fails for static method call expression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-10062) STC: no type parameter inference for variadic method called with fewer arguments than parameters
[
https://issues.apache.org/jira/browse/GROOVY-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10062.
--
Fix Version/s: 4.0.0-beta-1
Resolution: Fixed
> STC: no type parameter inference for variadic method called with fewer
> arguments than parameters
>
>
> Key: GROOVY-10062
> URL: https://issues.apache.org/jira/browse/GROOVY-10062
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1
>
>
> Consider the following:
> {code:groovy}
> def T m(T t, ... zeroOrMore) {
> }
> def obj = m(42)
> {code}
> When method "m" is called with just one argument, STC does not infer the type
> of "T".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10062) STC: no type parameter inference for variadic method called with fewer arguments than parameters
Eric Milles created GROOVY-10062:
Summary: STC: no type parameter inference for variadic method
called with fewer arguments than parameters
Key: GROOVY-10062
URL: https://issues.apache.org/jira/browse/GROOVY-10062
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Eric Milles
Assignee: Eric Milles
Consider the following:
{code:groovy}
def T m(T t, ... zeroOrMore) {
}
def obj = m(42)
{code}
When method "m" is called with just one argument, STC does not infer the type
of "T".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10059) Super Class Closure Can't Find Field when Any Method Overridden
[
https://issues.apache.org/jira/browse/GROOVY-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1739#comment-1739
]
Eric Milles edited comment on GROOVY-10059 at 4/27/21, 3:42 PM:
You can tag your class {{A}} or field {{foo}} with
{{@groovy.transform.CompileStatic}} and the necessary bridge methods will get
created so you can have this sort of construction.
was (Author: emilles):
You can tag your class {{A}} with {{@groovy.transform.CompileStatic}} and the
necessary bridge methods will get created so you can have this sort of
construction.
> Super Class Closure Can't Find Field when Any Method Overridden
> ---
>
> Key: GROOVY-10059
> URL: https://issues.apache.org/jira/browse/GROOVY-10059
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Ian
>Priority: Major
>
> {noformat}
> class A {
> private final boolean VAL = false
> Closure foo = {
> println VAL // Exception thrown from here
> }
> }
> class B {
> A a = new A() {} // Removing these braces makes it work as expected. Also
> fails if an actual method is overridden here
> def bar() {
> a.foo()
> }
> }
> new B().bar() // Running this throws exception
> //new A().foo() // Running this instead works as expected{noformat}
> Running this (script called OverrideFail.groovy) results in an exception:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: VAL for
> class: B
> Possible solutions: a
> groovy.lang.MissingPropertyException: No such property: VAL for class: B
> Possible solutions: a
> at A$_closure1.doCall(OverrideFail.groovy:4)
> at A$_closure1.doCall(OverrideFail.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at B.bar(OverrideFail.groovy:12)
> at B$bar.call(Unknown Source)
> at OverrideFail.run(OverrideFail.groovy:16)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10059) Super Class Closure Can't Find Field when Any Method Overridden
[
https://issues.apache.org/jira/browse/GROOVY-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1739#comment-1739
]
Eric Milles commented on GROOVY-10059:
--
You can tag your class {{A}} with {{@groovy.transform.CompileStatic}} and the
necessary bridge methods will get created so you can have this sort of
construction.
> Super Class Closure Can't Find Field when Any Method Overridden
> ---
>
> Key: GROOVY-10059
> URL: https://issues.apache.org/jira/browse/GROOVY-10059
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Ian
>Priority: Major
>
> {noformat}
> class A {
> private final boolean VAL = false
> Closure foo = {
> println VAL // Exception thrown from here
> }
> }
> class B {
> A a = new A() {} // Removing these braces makes it work as expected. Also
> fails if an actual method is overridden here
> def bar() {
> a.foo()
> }
> }
> new B().bar() // Running this throws exception
> //new A().foo() // Running this instead works as expected{noformat}
> Running this (script called OverrideFail.groovy) results in an exception:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: VAL for
> class: B
> Possible solutions: a
> groovy.lang.MissingPropertyException: No such property: VAL for class: B
> Possible solutions: a
> at A$_closure1.doCall(OverrideFail.groovy:4)
> at A$_closure1.doCall(OverrideFail.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at B.bar(OverrideFail.groovy:12)
> at B$bar.call(Unknown Source)
> at OverrideFail.run(OverrideFail.groovy:16)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10059) Super Class Closure Can't Find Field when Any Method Overridden
[
https://issues.apache.org/jira/browse/GROOVY-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1737#comment-1737
]
Ian commented on GROOVY-10059:
--
Perfect, thank you. I did search, but evidently missed that one.
> Super Class Closure Can't Find Field when Any Method Overridden
> ---
>
> Key: GROOVY-10059
> URL: https://issues.apache.org/jira/browse/GROOVY-10059
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Ian
>Priority: Major
>
> {noformat}
> class A {
> private final boolean VAL = false
> Closure foo = {
> println VAL // Exception thrown from here
> }
> }
> class B {
> A a = new A() {} // Removing these braces makes it work as expected. Also
> fails if an actual method is overridden here
> def bar() {
> a.foo()
> }
> }
> new B().bar() // Running this throws exception
> //new A().foo() // Running this instead works as expected{noformat}
> Running this (script called OverrideFail.groovy) results in an exception:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: VAL for
> class: B
> Possible solutions: a
> groovy.lang.MissingPropertyException: No such property: VAL for class: B
> Possible solutions: a
> at A$_closure1.doCall(OverrideFail.groovy:4)
> at A$_closure1.doCall(OverrideFail.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at B.bar(OverrideFail.groovy:12)
> at B$bar.call(Unknown Source)
> at OverrideFail.run(OverrideFail.groovy:16)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1726#comment-1726
]
Eric Milles edited comment on GROOVY-10055 at 4/27/21, 3:12 PM:
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code that tries to get a concrete type to work with (aka
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}) is getting Object in the
current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(TZ: "Europe/Paris")
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
was (Author: emilles):
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code that tries to get a concrete type to work with (aka
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}) is getting Object in the
current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical
[jira] [Comment Edited] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1726#comment-1726
]
Eric Milles edited comment on GROOVY-10055 at 4/27/21, 3:11 PM:
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code (aka
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}) that tries to get a
concrete type to work with is getting Object in the current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
was (Author: emilles):
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code that tries to get a concrete type to work with is getting
Object in the current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical workaround that can be further improved by using
> the "with"
[jira] [Comment Edited] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1726#comment-1726
]
Eric Milles edited comment on GROOVY-10055 at 4/27/21, 3:11 PM:
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code that tries to get a concrete type to work with (aka
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}) is getting Object in the
current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
was (Author: emilles):
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code (aka
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}) that tries to get a
concrete type to work with is getting Object in the current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical
[jira] [Commented] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1726#comment-1726
]
Eric Milles commented on GROOVY-10055:
--
You are using {{PostgreSQLContainer}} as a raw type, so there is no explicit
argument assigned to the {{SELF}} type parameter. Looks like the
"fully-resolve" code that tries to get a concrete type to work with is getting
Object in the current codebase.
If each of the "with" methods are returning "this" and not a new instance, your
grooviest workaround would be:
{code:groovy}
def postgreSqlServer = new PostgreSQLContainer().tap {
withExposedPorts(5432)
withEnv(["TZ": "Europe/Paris"])
withDatabaseName("my_database")
withUsername("user")
withPassword("pass")
}
{code}
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical workaround that can be further improved by using
> the "with" method.
> Tnx
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8965) instanceof with || inserts wrong cast
[
https://issues.apache.org/jira/browse/GROOVY-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8965:
---
Assignee: Eric Milles
> instanceof with || inserts wrong cast
> -
>
> Key: GROOVY-8965
> URL: https://issues.apache.org/jira/browse/GROOVY-8965
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.5
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>
> {code:java}
> @groovy.transform.CompileStatic
> def foo(a) {
> if (a instanceof Integer || a instanceof Double) {
> a.floatValue() // expected: cast to Number; actual: cast to Integer
> }
> }
> println foo(1d).class // CCE: java.lang.Double cannot be cast to
> java.lang.Integer
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9931) !instanceof inference does not work
[
https://issues.apache.org/jira/browse/GROOVY-9931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-9931:
---
Assignee: Eric Milles
> !instanceof inference does not work
> ---
>
> Key: GROOVY-9931
> URL: https://issues.apache.org/jira/browse/GROOVY-9931
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 3.0.7
>Reporter: Stefanos Chaliasos
>Assignee: Eric Milles
>Priority: Major
>
> I have the following Groovy program
>
> {code:groovy}
> @groovy.transform.CompileStatic
> class Main {
> static Integer bar(Object o) {
> if (o !instanceof Integer) {
> return 0
> } else {
> return o
> }
> }
> }
> {code}
> h2. Actual Behavior
> The program does not compile, and I get the following error.
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Main.groovy: 7: [Static type checking] - Cannot return value of type
> java.lang.Object on method returning type java.lang.Integer
> @ line 7, column 9.
>o
>^
> 1 error
> {code}
> h2. Expected Behavior
> Compile successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10059) Super Class Closure Can't Find Field when Any Method Overridden
[
https://issues.apache.org/jira/browse/GROOVY-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333280#comment-17333280
]
Eric Milles commented on GROOVY-10059:
--
Duplicate of GROOVY-5438, et al.
> Super Class Closure Can't Find Field when Any Method Overridden
> ---
>
> Key: GROOVY-10059
> URL: https://issues.apache.org/jira/browse/GROOVY-10059
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Ian
>Priority: Major
>
> {noformat}
> class A {
> private final boolean VAL = false
> Closure foo = {
> println VAL // Exception thrown from here
> }
> }
> class B {
> A a = new A() {} // Removing these braces makes it work as expected. Also
> fails if an actual method is overridden here
> def bar() {
> a.foo()
> }
> }
> new B().bar() // Running this throws exception
> //new A().foo() // Running this instead works as expected{noformat}
> Running this (script called OverrideFail.groovy) results in an exception:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: VAL for
> class: B
> Possible solutions: a
> groovy.lang.MissingPropertyException: No such property: VAL for class: B
> Possible solutions: a
> at A$_closure1.doCall(OverrideFail.groovy:4)
> at A$_closure1.doCall(OverrideFail.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at B.bar(OverrideFail.groovy:12)
> at B$bar.call(Unknown Source)
> at OverrideFail.run(OverrideFail.groovy:16)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-10059) Super Class Closure Can't Find Field when Any Method Overridden
[
https://issues.apache.org/jira/browse/GROOVY-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles closed GROOVY-10059.
Resolution: Duplicate
> Super Class Closure Can't Find Field when Any Method Overridden
> ---
>
> Key: GROOVY-10059
> URL: https://issues.apache.org/jira/browse/GROOVY-10059
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Ian
>Priority: Major
>
> {noformat}
> class A {
> private final boolean VAL = false
> Closure foo = {
> println VAL // Exception thrown from here
> }
> }
> class B {
> A a = new A() {} // Removing these braces makes it work as expected. Also
> fails if an actual method is overridden here
> def bar() {
> a.foo()
> }
> }
> new B().bar() // Running this throws exception
> //new A().foo() // Running this instead works as expected{noformat}
> Running this (script called OverrideFail.groovy) results in an exception:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: VAL for
> class: B
> Possible solutions: a
> groovy.lang.MissingPropertyException: No such property: VAL for class: B
> Possible solutions: a
> at A$_closure1.doCall(OverrideFail.groovy:4)
> at A$_closure1.doCall(OverrideFail.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at B.bar(OverrideFail.groovy:12)
> at B$bar.call(Unknown Source)
> at OverrideFail.run(OverrideFail.groovy:16)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
