:wave: hoping this is the right channel to ask thi...

# kontributors

[kevinmost]

👋 hoping this is the right channel to ask this, I figured a lot of the discussions around the Kotlin internals happens here. I was looking at the Kotlin compiler plugins (namely, no-arg and Parcelize, which I figured were some of the simpler ones), trying to get a feel for them. I'd love to contribute to compiler plugin work at some point.

I noticed that they're generating bytecode directly: https://github.com/JetBrains/kotlin/blob/master/plugins/noarg/noarg-cli/src/NoArgExpressionCodegenExtension.kt#L54

Is it feasible and/or desirable to generate Kotlin source code (now that KotlinPoet is a thing, though it's still early-stage from what I understand), run it through the embedded Kotlin compiler, and emit the generated bytecode from that instead? It seems more maintainable and less error-prone, at least from my perspective, to generate source code than to try to write out bytecode by hand.

Just trying to get some perspective on the way the plugins are written, I assume that one of the main reasons for writing bytecode is just that KotlinPoet is new, and compiler plugins have been a thing for a while now 🙂

[r4zzz4k]

Are you sure that generating untyped text representation of the code and then translating it to AST by compiler is less error-prone than modifying AST directly?

[yole]

in the long run, the plugins will be generating IR, which is more maintainable than either source code or raw bytecode

[kevinmost]

Not generating an untyped text representation. I agree that string-concatenation manually is quite error-prone and it seems clear to me that that was an early factor in why they would choose to generate bytecode. I was mainly curious if using a type-safe source code generator like what KotlinPoet provides, and then letting the compiler convert that to raw bytecode, is a viable path forward when generating a plugin

[kevinmost]

@yole Hm, interesting. So currently, they're just generating raw bytecode, from what I see. I assume this is infeasible in terms of, for example, generating code that works on multiplatform, and that the motivation in moving to IR would be not just maintainability, but also multiplatform support?

[yole]

“run it through the embedded Kotlin compiler” is far more difficult than it sounds like when we’re talking about modifications inside an existing user class

[yole]

yes, IR will also enable compiler plugins with other backends

[kevinmost]

I see, that makes sense. Generating source would work in terms of generating new classes, but I suppose we already have annotation processors for that, so the majority of compiler plugins are modifying bytecode to get around this at the moment

[kevinmost]

does that sound right?

[r4zzz4k]

@kevinmost I see what you mean. Sounds reasonable to have a bit more high-level stuff, but still text source code seems excessive.
@yole, thanks for clarification!

[yole]

yep, sounds right

[kevinmost]

great, thanks for the clarifications! I assume that the move off bytecode to IR is a longer-term effort and probably lower priority than a lot of other projects, so I assume that for the foreseeable future, it's going to be all bytecode generation 🙂

[yole]

IR is actually one of the high priority projects for 1.3

[kevinmost]

Oh, nice to hear! Do you know if there's a Youtrack I can follow for that project?

[yole]

there isn’t one

[kevinmost]

👍 No worries, I'll just keep an eye on the compiler plugins once 1.3 is out

[raulraja]

quasiquotes as in scala meta offer also a great type safe way to manipulate the AST that feels like dealing with sources directly https://github.com/scalameta/scalameta/blob/master/notes/quasiquotes.md

[dmitry.petrov]

Smart macros work fine in the stand-alone compiler. Unfortunately, not in the tooling. So far, the best solution for this problem is to provide specific plug-ins along with macro libraries.