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. -- 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]
