Scott Murphy Heiberg created GROOVY-12693:
---------------------------------------------
Summary: STC: @CompileStatic/@TypeChecked on a local variable
fails with "Unimplemented node type"
Key: GROOVY-12693
URL: https://issues.apache.org/jira/browse/GROOVY-12693
Project: Groovy
Issue Type: Bug
Affects Versions: 6.0.0
Reporter: Scott Murphy Heiberg
*Affects Version:* 6.0.0 (also 5.0.8, the GROOVY_6_0_X branch and master)
*Environment:* macOS 26.5, JDK 21.0.12 (BellSoft Liberica); groovy / groovyc
command line, same result with GroovyShell
h3. Problem
{{@groovy.transform.CompileStatic}} and {{@groovy.transform.TypeChecked}}
declare {{@Target({TYPE, METHOD, CONSTRUCTOR})}}. Placing one of them on a
local variable declaration does not produce the usual annotation target
diagnostic; the type checker reports an internal fallback message instead.
{code:groovy}
@groovy.transform.CompileStatic
int x = 1
println x
{code}
{noformat}
$ groovy local.groovy
local.groovy: 1: [Static type checking] - Unimplemented node type @ line 1,
column 1.
@groovy.transform.CompileStatic
^
1 error
$ groovyc --check --error-format=short local.groovy
local.groovy:1:1: error: [Static type checking] - Unimplemented node type
{noformat}
The same message appears with {{@TypeChecked}}, with {{def x = 1}}, {{val x =
1}}, {{def (a, b) = [1, 2]}}, with the declaration inside a method body
(reported at the declaration's position), and when either annotation is placed
on a field, a property or a parameter:
{code:groovy}
class C {
@groovy.transform.CompileStatic private int f = 1 // Unimplemented
node type @ line 2, column 5
void m(@groovy.transform.TypeChecked int p) { } // Unimplemented
node type @ line 3, column 12
}
{code}
On a loop statement (annotations on loop statements are accepted by the parser
since 6.0.0) the transformation does not even get as far as a diagnostic:
{code:groovy}
@groovy.transform.CompileStatic
for (int i in 1..2) println i
{code}
{noformat}
General error during canonicalization: class
org.codehaus.groovy.ast.stmt.ForStatement cannot be cast to class
org.codehaus.groovy.ast.AnnotatedNode (...)
java.lang.ClassCastException: class org.codehaus.groovy.ast.stmt.ForStatement
cannot be cast to class org.codehaus.groovy.ast.AnnotatedNode (...)
at
org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:60)
at
org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:173)
{noformat}
For comparison, an annotation without an AST transformation gets the expected
diagnostic:
{code:groovy}
@Override
int x = 1
{code}
{noformat}
local.groovy: 1: Annotation @java.lang.Override is not allowed on element
LOCAL_VARIABLE
@ line 1, column 1.
{noformat}
h3. Expected behaviour
The documentation (Semantics, "The @TypeChecked annotation" / "The
@CompileStatic annotation") says the annotations go on a class or a method, and
their {{@Target}} says the same. Any other placement should be rejected with
the standard target diagnostic, as for every other annotation:
{noformat}
Annotation @groovy.transform.CompileStatic is not allowed on element
LOCAL_VARIABLE
{noformat}
(and {{FIELD}}, {{PARAMETER}}, {{STATEMENT}} for the other placements).
"Unimplemented node type" describes the transformation's internal dispatch, not
the user's mistake, and the {{ClassCastException}} is a compiler crash.
h3. Cause
{{ExtendedVerifier}} does check annotation targets for local variables, fields,
parameters and loop statements, but it runs during class generation.
{{StaticTypesTransformation.visit}} and {{StaticCompileTransformation.visit}}
run earlier (instruction selection); they cast {{nodes[1]}} to
{{AnnotatedNode}} and, for anything other than a {{ClassNode}}, {{MethodNode}}
or {{PropertyNode}}, add the "Unimplemented node type" error themselves, so
compilation stops before the verifier ever reports the real problem. For a loop
statement {{nodes[1]}} is a {{Statement}}, which is not an {{AnnotatedNode}},
hence the {{ClassCastException}}.
A pull request with regression tests follows.
h3. Versions
Reproduced on 5.0.8, 6.0.0, 6.0.1-SNAPSHOT (GROOVY_6_0_X at 7c0dcf17dd) and
master (7.0.0-SNAPSHOT at d86ea7eb85). On 5.0.8 the loop statement variant is a
parse error instead because statement annotations did not exist yet.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
