[
https://issues.apache.org/jira/browse/GROOVY-10770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611929#comment-17611929
]
Eric Milles commented on GROOVY-10770:
--------------------------------------
One thing that you might consider is using "context" or "scopes" within your
check script to implement the notion of nested checks.
As far as supporting the stated scenario, a couple caveats:
# If {{CompileStatic}} or {{TypeChecked}} is applied via compiler
configuration, then the annotations can be applied first. That is, in your
example "erroneously-skipped.groovy" would be run first and by itself if
"some-extension.groovy" had been applied not as an annotation but via
configuration. (May not apply to you -- just something to be aware of.)
# The inside-out running order might be left on the cutting room floor.
# Nesting {{CompileStatic}} within {{TypeChecked}} and vice-versa may or may
not work; there is an open ticket for a scenario like this:
{code:groovy}
@CompileStatic
class C {
// ...
@CompileDynamic @TypeChecked
def m() {
// still want STC, just not SC
}
}
{code}
> Multiple @CompileStatic annotations don't combine extensions
> ------------------------------------------------------------
>
> Key: GROOVY-10770
> URL: https://issues.apache.org/jira/browse/GROOVY-10770
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 4.0.5
> Reporter: Christopher Smith
> Assignee: Eric Milles
> Priority: Major
>
> When multiple levels of {{@CompileStatic}} are present, various type-checking
> extensions can be specified independently, but the total list isn't
> aggregated:
> {code:groovy}
> @CompileStatic(extensions = 'some-extension.groovy')
> class MyClass {
> @CompileStatic(extensions = 'erroneously-skipped.groovy')
> def myMethod() {}
> }
> {code}
> In such a case, all extensions should be applied collectively, inmost first.
> It might also make sense at some point to add some configuration to
> undo/disable other extensions, but for now composition is the piece that's
> not working correctly.
> I speculate that unified handling for {{@CompileStatic}} and {{@TypeChecked}}
> might be needed to make the various flavors all work together as expected by
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)