[
https://issues.apache.org/jira/browse/GROOVY-12553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134512#comment-18134512
]
ASF GitHub Bot commented on GROOVY-12553:
-----------------------------------------
jdaugherty commented on PR #3082:
URL: https://github.com/apache/groovy/pull/3082#issuecomment-6511275939
Thanks for the look.
1. I'd rather not add a type check. `visitClass` already lets any private
superclass field of that name through, whatever its type, and adds this class's
own logger field, so the reference is to this class's field regardless. A type
check would keep the field but drop the guard, which is the bug here. It would
also break mixed strategies (a precompiled `@Slf4j` superclass under an `@Log`
subclass has a different field type, but the reference is still to the
subclass's field), and `LoggingStrategy` exposes no logger type to compare
against anyway.
2. Deliberately out of scope: a protected or package-private `log` in the
superclass is already a compile error from the existing check in `visitClass`,
and no logger field is created on that path, so the guard must not be
attempted. That is what the `isPrivate()` test preserves.
3. Yes.
I can widen the javadoc on `refersToLogField`, since the same binding
happens for a private `log` declared explicitly in a superclass compiled in the
same run, not only one read from bytecode.
> @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)
