I'm looking for resources on writing compiler plugins. So far I found: - <https://youtu.be/w-GMlaziI...

# compiler

[Piotr Krzemiński]

I'm looking for resources on writing compiler plugins. So far I found:
•

https://youtu.be/w-GMlaziIyo▾

• https://bnorm.medium.com/writing-your-second-kotlin-compiler-plugin-part-1-project-setup-7b05c7d93f6c
but I'm aware that the API moves fast. Is there some fresh tutorial or example plugin? I've been looking around source code of existing plugins, but first I want to check if there are some guides.

[Big Chungus]

No guides, just pretty much following bnorm blog and using .dump() a lot to inspect the general structure.

[Big Chungus]

That's how I got going. People here also help with word-of-mouth knowledge sharing on case-by-case basis

[Piotr Krzemiński]

Thanks! For context: my goal is to move generation of GitHub action wrappers in github-workflows-kt to a compiler plugin. Right now they are bundled with the library so their updates are bound to the library's release cycle. There's a long way to rely solely on the plugin, but I want to start. Primarily, I need to check if it's possible to use third-party compiler plugins in Kotlin Script.

[Big Chungus]

Hmm, you certainly can add compiler plugins to scripts, but it's not pretty. I'm not sure it's the way to go for your usecase. Why don't you publish each action wrapper as its own artefact instead?

[Big Chungus]

It's been discussed here if you're interested https://kotlinlang.slack.com/archives/C0BT46EL8/p1666122350091069?thread_ts=1666122350.091069&amp;cid=C0BT46EL8

[Piotr Krzemiński]

Why don’t you publish each action wrapper as its own artefact instead?

my goal is to make the DSL library scalable in terms of the number of supported actions, and ultimately unaware of the actions that it can support. I want to achieve it by asking the action authors to use https://github.com/krzema12/github-actions-typing/. As a maintainer of the DSL library, I don’t want to be responsible for publishing separate artefacts - it does sound complicated because publication failures happen and automation to release these would have to be created, and I simply want to avoid being the middleman. That’s of course the ideal world, my current northern star

[Piotr Krzemiński]

cool question, BTW - happy to discuss it further in #github-workflows-kt if you want!

[Big Chungus]

So what's your idea for the compiler plugin? Fetch action typings injected via some annotation on an empty interface and generate actions methods on the fly?

[Piotr Krzemiński]

yep, that’s my initial idea

[Piotr Krzemiński]

still thinking about a cleaner API, but it would be bearable I think

[Big Chungus]

You won't get any IDE support for that unless you also write FIR plugin (which is even less stable/documented)

[Big Chungus]

While your idea is sound, I think it's much too early for that

[Piotr Krzemiński]

Got it - yeah, I don't want to introduce this change just yet, just wanted to play around with compiler API and build a little PoC

[Big Chungus]

You could build a backend IR plugin for this fairly easy, but at the moment end user experience would be terrible. Not only will they have to add the plugin via kotlinc cli, but they will also need to write their scripts blindly without any intellisense

[Piotr Krzemiński]

Yes, true - I realize that

[Big Chungus]

I'd suggest just having a scheduled github ci job that would somehow scan known repos that use action types and would generate/publish wrapper artefacts for new versions

[Big Chungus]

Complex one-time setup that can run unattended afterwards and have much better end user experience

[Big Chungus]

In the current state of kotlin ecosystem at least

[Big Chungus]

You can also have some readme page on the repo that ci would record latest published wrapper artefacts for discoverability

[Piotr Krzemiński]

That's exactly my plan B, or a mid-term one until Kotlin allows for more

[Big Chungus]

Just some alternative ideas for you short-term

[Piotr Krzemiński]

Great, thanks a lot for digging deeper with me and helping me realize what's missing in Kotlin :)

[Big Chungus]

Happy to help with CI stuff if you get stuck. Just ping me.

[Piotr Krzemiński]

Ah, I fancy the CI stuff myself 😉

[Big Chungus]

I think you could copy a lot of infra from kamp scan job to give you a head start

[Big Chungus]

Ah, I fancy the CI stuff myself 😉

We're the minority on that 😀

[Big Chungus]

Anyways, do report back on #github-workflows-kt when you make some progress. Curious to see where it ends up.

[Piotr Krzemiński]

BTW, I'd like to better understand what FIR plugins are. I understand they're related to IDE support and that FIR stands for Frontend IR (right?). But why aren't just backend IR plugins enough for the IDE? Do compiler plugins always come in pairs (backend and frontend), like socks? And finally, is FIR plugin needed if I plan to work only with backend IR? What would the plugin do in such case?

[Big Chungus]

I'd love a good explanation on that too. So far it's very confusing 😀 Maybe ask in a separate thread on this channel?

[Piotr Krzemiński]

https://kotlinlang.slack.com/archives/C7L3JB43G/p1669393266130419

[Johannes Barop]

@Piotr Krzemiński What do you mean with "IDE support"?

I am also just getting into the world of compiler plugins.

In a plugin I implemented a method from an interface. In IntelliJ there were errors because IntelliJ didn't know about it.

I wrote an Intellij plugin that references the "SyntheticResolveExtension" of the plugin. With this it works. But you have to provide an IntelliJ plugin...