Changes needed for compiler plugin

[neeme-praks-sympower]

See also:

• KLogger does not properly populate SLF4J/Logback ILoggingEvent "message" field #449
• Kotlin compiler plugin #470

[neeme-praks-sympower]

@oshai, can you have a look at these small changes? I want to merge this in before I move compiler plugin to a separate repository.

[oshai]

Looking at it now.

The change in LogbackLoggerFactory seems ok, but if possible I would like to avoid the rest. Even on the expense of some duplication on the compiler plugin.

public extension functions can really clutter IDE autocomplete and confuses users. So I suggest to have them in a separate module, either only dependent at runtime, or bundle with the compiler plugin somehow.

[oshai]

Another option: Mark methods as deprecated - I think there is an option they will only be visible to compiler.

[neeme-praks-sympower]

The change in LogbackLoggerFactory seems ok, but if possible I would like to avoid the rest. Even on the expense of some duplication on the compiler plugin.

public extension functions can really clutter IDE autocomplete and confuses users. So I suggest to have them in a separate module, either only dependent at runtime, or bundle with the compiler plugin somehow.

These extension functions can be replaced with static non-extension functions. Would that be acceptable? While less elegant to read, at least they will not show up in IDE auto-complete.

I would like to avoid run-time dependency on the compiler plugin project.

[oshai]

Non extension functions is also an option. iiuc it will only be seen in bytecode inspection, right?

[neeme-praks-sympower]

Non extension functions is also an option. iiuc it will only be seen in bytecode inspection, right?

The functions themselves are visible on the classpath but IDE will not suggest them as they are not defined as (extension) functions on particular type.

[oshai]

Non extension functions is also an option. iiuc it will only be seen in bytecode inspection, right?

The functions themselves are visible on the classpath but IDE will not suggest them as they are not defined as (extension) functions on particular type.

yes I understand that. If the package or class name is marked as internal I expect users to understand that they shouldn't use it or rely on it.

Again, it's also possible to use the "HIDDEN" deprecation level as well so users can use it: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-deprecation-level/#412239310%2FClasslikes%2F1895087430

Maybe we can do that (hidden) also to internalCompilerData field.

[neeme-praks-sympower]

yes I understand that. If the package or class name is marked as internal I expect users to understand that they shouldn't use it or rely on it.

Again, it's also possible to use the "HIDDEN" deprecation level as well so users can use it: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-deprecation-level/#412239310%2FClasslikes%2F1895087430

Maybe we can do that (hidden) also to internalCompilerData field.

If we make internalCompilerData field hidden then we can no longer compile kotlin-logging itself -- we need read access to this field.

Here is a trick that works:

• We can use the deprecation annotation to hide all the functions that are called only by the compiler plugin. Then they can stay as extension functions.
• However, we cannot hide functions/members that we want to access ourselves from kotlin-logging code. But we can declare such functions/members as internal.

So, for internalCompilerData field, we can declare it as internal so it is accessible only from within kotlin-logging and then we can add a hidden extension function to KLoggingEventBuilder that we use to set the field from within the compiler plugin. This will give us the best of both worlds. Pretty neat.

I now applied this change, have a look.

[neeme-praks-sympower]

I now hid also toStringSafe() and castToThrowable() extension functions, using the same mechanism. Ok, the latter was already hidden, I just moved it to the same file with all the other hidden functions (and renamed the file).

[oshai]

lgtm. anything you would like to add before I merge it?

[neeme-praks-sympower]

lgtm. anything you would like to add before I merge it?

Nope, should be complete from my side.

[oshai]

merged, thanks!