[
https://issues.apache.org/jira/browse/GROOVY-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Smith updated GROOVY-7712:
--------------------------------------
Description:
It's possible that this is simply underdefined behavior, but it feels like a
bug, and I propose that the correct behavior should be as described below.
In an AST transformation running during the {{SEMANTIC_ANALYSIS}} phase, I can
add an annotation to an element that should trigger another transformation
running during a later phase (such as {{CANONICALIZATION}}):
{code}
@Override
protected void doVisit(AnnotationNode annotationNode, AnnotatedNode
annotatedNode) {
annotatedNode.addAnnotation(new AnnotationNode(make(OtherTransform.class)));
}
{code}
This successfully adds {{@OtherTransform}} to the node (visible in the class
output with the appropriate retention policy), but the transformation tied to
{{@OtherTransform}} does not execute; it works fine if {{@OtherTransform}} is
explicitly annotated on the node in the source code.
It appears that all annotations are scanned once for transformations by the
{{ASTTransformationCollectorCodeVisitor}} and queued for processing, so that
annotations added later are never scanned. Instead, a transformation operating
in an earlier phase ought to be able to leave behind an instruction for one to
be applied in a later phase, at a minimum through a mechanism to imperatively
notify the compilation unit that the transformation should be applied to the
node.
was:
It's possible that this is simply underdefined behavior, but it feels like a
bug, and I propose that the correct behavior should be as described below.
In an AST transformation running during the {{SEMANTIC_ANALYSIS}} phase, I can
add an annotation to an element that should trigger another transformation
running during a later phase (such as {{CANONICALIZATION}}):
{code}
@Override
protected void doVisit(AnnotationNode annotationNode, AnnotatedNode
annotatedNode) {
annotatedNode.addAnnotation(new AnnotationNode(make(OtherTransform.class)));
}
{code}
This successfully adds {{@OtherTransform}} to the node (visible in the class
output with the appropriate retention policy), but the transformation tied to
{{@OtherTransform}} does not execute; it works fine if {{@OtherTransform}} is
explicitly annotated on the node in the source code.
It appears that all annotations are scanned once for transformations and queued
for processing, so that annotations added later are never scanned. Instead, a
transformation operating in an earlier phase ought to be able to leave behind
an instruction for one to be applied in a later phase.
> annotations for AST transformations should be inspected at each phase
> ---------------------------------------------------------------------
>
> Key: GROOVY-7712
> URL: https://issues.apache.org/jira/browse/GROOVY-7712
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.4.5
> Reporter: Christopher Smith
>
> It's possible that this is simply underdefined behavior, but it feels like a
> bug, and I propose that the correct behavior should be as described below.
> In an AST transformation running during the {{SEMANTIC_ANALYSIS}} phase, I
> can add an annotation to an element that should trigger another
> transformation running during a later phase (such as {{CANONICALIZATION}}):
> {code}
> @Override
> protected void doVisit(AnnotationNode annotationNode, AnnotatedNode
> annotatedNode) {
> annotatedNode.addAnnotation(new
> AnnotationNode(make(OtherTransform.class)));
> }
> {code}
> This successfully adds {{@OtherTransform}} to the node (visible in the class
> output with the appropriate retention policy), but the transformation tied to
> {{@OtherTransform}} does not execute; it works fine if {{@OtherTransform}} is
> explicitly annotated on the node in the source code.
> It appears that all annotations are scanned once for transformations by the
> {{ASTTransformationCollectorCodeVisitor}} and queued for processing, so that
> annotations added later are never scanned. Instead, a transformation
> operating in an earlier phase ought to be able to leave behind an instruction
> for one to be applied in a later phase, at a minimum through a mechanism to
> imperatively notify the compilation unit that the transformation should be
> applied to the node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
