[
https://issues.apache.org/jira/browse/GROOVY-12553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136932#comment-18136932
]
ASF GitHub Bot commented on GROOVY-12553:
-----------------------------------------
jdaugherty commented on PR #3082:
URL: https://github.com/apache/groovy/pull/3082#issuecomment-6592858556
Thanks. Added your test, and the property cases as a parameterized test over
`def log`, `static log` and `String log`, each also checking that the call uses
`Sub.log`. All of them fail on master and pass with the fix.
One small correction to the reasoning: the test compares the class files and
never runs `Sub`, so if the guard were bound to the superclass's field it would
fail on the missing `IFEQ` rather than on `String` lacking `isLoggable`.
Confirmed the joint-compilation case: on master, every explicitly declared
`log` in the superclass drops the guard in both compilations, so `together ==
separate` holds there and the `IFEQ` assertion is what catches it. Only a
`@Log` superclass compiled in the same run differs, since its field does not
exist yet when the subclass is scoped. I have reworded the commit message and
description accordingly and widened the javadoc on `refersToLogField`. The
backport branch is updated to match.
> @Log: a log call in a subclass is not guarded when the superclass with its
> own @Log is already compiled
> -------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12553
> URL: https://issues.apache.org/jira/browse/GROOVY-12553
> Project: Groovy
> Issue Type: Bug
> Components: AST Transforms
> Affects Versions: 4.0.33, 5.1.3
> Reporter: James Daugherty
> Priority: Major
>
> {{@Log}}, {{@Slf4j}} and the other logging annotations wrap a log call whose
> arguments are not trivial in a level check, so {{log.fine('value: ' +
> value)}} compiles as {{if (log.isLoggable(Level.FINE)) log.fine('value: ' +
> value)}}. When the class extends another class with a logging annotation, the
> guard is only added while the superclass is compiled together with it. When
> the superclass is already compiled, the call is left unguarded, so its
> arguments are evaluated whatever the level, and the same source compiles to a
> different class file depending on what else is compiled.
> {code:groovy}
> @groovy.util.logging.Log
> abstract class Base {
> void start() { log.info('starting ' + getClass().simpleName) }
> }
> @groovy.util.logging.Log
> class Sub extends Base {
> void run(Object value) {
> log.fine('value: ' + value) // not guarded when Base is already
> compiled
> }
> }
> {code}
> Reproduced with 4.0.33, 5.1.3 and master. A reproducer with a groovyc script
> and an incremental Gradle build:
> https://github.com/jdaugherty/groovy-log-guard-precompiled-superclass
> *Cause*
> {{LogASTTransformation}} adds the guard only when the {{log}} variable of the
> call is still a {{DynamicVariable}}, unbound because the log field is added
> by the transformation itself. With the superclass read from bytecode, the
> reference has already been bound to the superclass's own private {{log}}
> field, so the call is left unguarded. The transformation already accepts such
> a private field when it adds the subclass's log field.
> *Proposed fix*
> Treat a reference bound to a private field of another class the same as an
> unbound one.
> Found while making incremental builds of a Grails application produce the
> same classes as a full build; see also GROOVY-12550 and GROOVY-12544.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
