paulk-asert opened a new pull request, #2829: URL: https://github.com/apache/groovy/pull/2829
GROOVY-12292: https://issues.apache.org/jira/browse/GROOVY-12292 A method-level `@TypeChecked` or `@CompileStatic` annotation with the default (non-SKIP) mode was silently ignored when the declaring class carried a SKIP-mode annotation. Four combinations were affected: - `@CompileDynamic` class + `@CompileStatic` method - `@CompileStatic(SKIP)` class + `@CompileStatic` method - `@TypeChecked(SKIP)` class + `@CompileStatic` method - `@TypeChecked(SKIP)` class + `@TypeChecked` method The cause is in `StaticTypeCheckingVisitor#isSkipMode`, which recursed to the declaring class without first considering that the method's own annotation had already answered the question. Nested classes take a different code path and already honour the more specific annotation (GROOVY-10238), as does the opt-out direction (checked class + SKIP method), making methods the lone anomaly. The behaviour is longstanding (reproduced identically on 4.0.27, 5.0.6 and 6.0.0-alpha-1). The fix stops the walk up to the declaring class when the node itself carries one of the visitor's type-checking annotations with a non-SKIP mode: the most specific annotation wins, and a class-level SKIP remains the default for members without their own annotation. Because `StaticCompileTransformation` derives the `STATIC_COMPILE_NODE` metadata from the same method, bytecode generation follows: an opted-in method under a `@CompileDynamic` class is now statically compiled, not just checked (asserted in the new bytecode test). Deliberately unchanged, now ratified by tests and documentation: - opt-out direction: SKIP-mode methods inside checked classes are skipped as before; - cross-family behaviour: method-level `@CompileStatic(SKIP)` / `@CompileDynamic` disables static compilation but does not exempt the method from an enclosing class's `@TypeChecked` checking; only `@TypeChecked(SKIP)` does. Since the change means previously-dynamic (and unchecked) method bodies are now checked and statically compiled, it is behaviour-changing: a COMPATIBILITY.md entry is included and the JIRA issue should get the `breaking` label, targeting 6.0 only. Documentation of the precedence rules is added to the "Skipping sections" part of core-semantics.adoc. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
