[
https://issues.apache.org/jira/browse/GROOVY-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Octavia Togami updated GROOVY-10725:
------------------------------------
Description:
In 3.0.12 the following code fails to pass STC:
{code:groovy}
@groovy.transform.CompileStatic
class Request {
Enumeration<String> getHeaderNames() {
def r = new Vector()
r.add("Header")
r.elements()
}
String getHeader(String header) {
"value"
}
}
@groovy.transform.CompileStatic
class Test {
void test() {
def request = new Request()
Set<Map<String, String>> allHeaders = []
allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
headerName -> [headerName, request.getHeader(headerName)] })
}
}
new Test().test()
{code}
Error:
{code:groovy}
$ groovy fail.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/home/octy/Documents/groovy_playground/fail.groovy: 18: [Static type checking]
- Cannot call <T> java.util.Set <Map>#addAll(T[]) with arguments
[java.lang.Object]
@ line 18, column 7.
allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
headerName -> [headerName, request.getHeader(headerName)] })
^
1 error
{code}
This is not a total blocker, as the generics can be specified to
`collectEntries`, or the expression extracted to a typed variable; and the
error will go away. However, it does make existing code fail to compile, when
it worked under 3.0.11.
was:
In 3.0.12 the following code fails to pass STC:
{code:groovy}
@groovy.transform.CompileStatic
class Request {
Enumeration<String> getHeaderNames() {
def r = new Vector()
r.add("Header")
r.elements()
}
String getHeader(String header) {
"value"
}
}
@groovy.transform.CompileStatic
class Test {
void test() {
def request = new Request()
Set<Map<String, String>> allHeaders = []
allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
headerName -> [headerName, request.getHeader(headerName)] })
}
}
new Test().test()
{code}
Error:
{code:groovy}
groovy fail.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/home/octy/Documents/groovy_playground/fail.groovy: 18: [Static type checking]
- Cannot call <T> java.util.Set <Map>#addAll(T[]) with arguments
[java.lang.Object]
@ line 18, column 7.
allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
headerName -> [headerName, request.getHeader(headerName)] })
^
1 error
{code}
This is not a total blocker, as the generics can be specified to
`collectEntries`, or the expression extracted to a typed variable; and the
error will go away. However, it does make existing code fail to compile, when
it worked under 3.0.11.
> Regression in STC related to generics, unknown cause
> ----------------------------------------------------
>
> Key: GROOVY-10725
> URL: https://issues.apache.org/jira/browse/GROOVY-10725
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 3.0.12
> Environment: Linux, Groovy 3.0.12, Java 8
> Reporter: Octavia Togami
> Priority: Major
>
> In 3.0.12 the following code fails to pass STC:
> {code:groovy}
> @groovy.transform.CompileStatic
> class Request {
> Enumeration<String> getHeaderNames() {
> def r = new Vector()
> r.add("Header")
> r.elements()
> }
> String getHeader(String header) {
> "value"
> }
> }
> @groovy.transform.CompileStatic
> class Test {
> void test() {
> def request = new Request()
> Set<Map<String, String>> allHeaders = []
> allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
> headerName -> [headerName, request.getHeader(headerName)] })
> }
> }
> new Test().test()
> {code}
> Error:
> {code:groovy}
> $ groovy fail.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/octy/Documents/groovy_playground/fail.groovy: 18: [Static type
> checking] - Cannot call <T> java.util.Set <Map>#addAll(T[]) with arguments
> [java.lang.Object]
> @ line 18, column 7.
> allHeaders.addAll(request.getHeaderNames().toList().collectEntries {
> headerName -> [headerName, request.getHeader(headerName)] })
> ^
> 1 error
> {code}
> This is not a total blocker, as the generics can be specified to
> `collectEntries`, or the expression extracted to a typed variable; and the
> error will go away. However, it does make existing code fail to compile, when
> it worked under 3.0.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
