Is there any (recommended) way to test FIR plugins? I know it's still completely unstable, but I'd l...

# compiler

[Youssef Shoaib [MOD]]

Is there any (recommended) way to test FIR plugins? I know it's still completely unstable, but I'd like to try out a few things. I tried using kotlin-compile-testing (which I already use for testing IR plugins) but the compiler complained about K2 not supporting plugins.

Looking at fir-plugin-prototype, there's some mentions of a Kotlin compiler testing API, but I can't figure out what artifact it lives in or how to even use it. Is there any way to just let the K2 compiler accept that I'm using plugins? And if not, is there any basic guidance on using the Kotlin compiler testing API that fir-plugin-prototype uses?

[shikasd]

Maybe jetbrains have some hidden tooling to test their own plugins in Kotlin repo?

[Youssef Shoaib [MOD]]

It looked like there is some API that they're using that I guess simply bypasses those checks. It looks like arrow-inject is using it too, so I think it is public? Not fully sure tho, hence why I'm asking here lol

[dmitriy.novozhilov]

Check this repo
It is fully set up for FIR plugins testing
https://github.com/demiurg906/kotlin-compiler-course-examples/tree/compiler-plugin-project-setup

[dmitriy.novozhilov]

But I suggest to wait till next Wednesday, when I publish new bootstrap version of compiler
It will contain some improvements to the API

[Youssef Shoaib [MOD]]

Oooooooooo, to the FIR API in general or to the testing API specifically?

[dmitriy.novozhilov]

@shikasd it's not hidden. It is published and even documented
https://github.com/JetBrains/kotlin/blob/master/compiler/test-infrastructure/ReadMe.md

[dmitriy.novozhilov]

Oooooooooo, to the FIR API in general or to the testing API specifically?

To the FIR API
Testing API is quite stable

[shikasd]

Ohh, that's great
I've been mostly working with Compose test framework, so haven't seen the newest updates

[dmitriy.novozhilov]

AFAIR we almost convinced compose team to migrate to our framework
But I don't remember their final decision

[Zac Sweers]

why would a plugin choose FIR vs IR (either/or)? I think this is a bit unclear right now

[Javier]

Overall when you want to report errors to the user instead of failing only when it compiles.

For example, there is no way to know if a provider is missing with Dagger if the project is not compiled. Arrow Inject is able to know that a provider is missing so it reports that error in the IDE and if you run it via CLI it should fail in the frontend phase

[Javier]

You need Fir + Ir when you are not only reporting things in Fir. For example, a function can compile in Fir, but it may not be valid in Ir, so you have to replace it with a valid function in Ir.

[Javier]

And you may want to generate functions that are going to be used by the user. For example, Dagger code generation is not used by the user directly, so the codegen itself should be useless in terms of allowing the user to use it before it compiles.

Meanwhile Kotlin Serialization generates a function, serializer() which can be used by the user, and the user must be able to use it directly, having it as error/red, then running a Gradle task which generates it, and then the error is gone is not a very good experience

It is better to generate it at same time the user finishes of writing @Serializable in the IDE so the user is able to use it directly.

[Javier]

With dagger codegen not used by the user I was referring to Hilt, because Dagger 2 vanilla was generating classes that they were red but after building they were available so everything compiles fine.

[shikasd]

why would a plugin choose FIR vs IR (either/or)?

@Zac Sweers
You won't, really
Instead, it is a choice between PSI/descriptor based apis and FIR for extension, with better opportunities for extension in the latter (once it is stable)

[Zac Sweers]

Why would compose use FIR?

[Zac Sweers]

Vs IR

[Zac Sweers]

I didn't follow that discussion above

[shikasd]

The discussion above was about Kotlin compiler test apis, I think :)

[shikasd]

Compose will have to support FIR for Composable - related checks done inside checkers atm, I believe
But this plugin will have to use both FIR and IR

[Javier]

@shikasd how compose is integrated right now to show errors about it? IDE embedded plugin?

[Javier]

@Zac Sweers another example:

you generate a function in Fir called foo (with Fir you can't generate function bodies).

The return type of that function is a String.

Then the user can write

val someString: String = foo()

That compiles in the frontend, the user see no errors, but IR backend will fail because… what is going to return it? It has to return something of type String but which is this value if it can't be provided in Fir? You have to fix that in backend, if not it will fail.

So it is not a FIR vs IR. Depending on the use case you need the first one, the second one or both.

In compose there are IDE errors related to using a composable outside a composable context, that job can be done by FIR. Not sure how it is done right now tbh.

[shikasd]

You can write frontend plugins without fir as well, e.g. with Call/DeclarationChecker or SyntheticResolve/AnalysisHandlerExtension

[Youssef Shoaib [MOD]]

AFAIK, AnalysisHandlerExtension only works In the current Front End (i.e. FE1.0) and won't work in FIR

[shikasd]

Yep, that's how you write frontend plugins without using FIR (answer to the question above)

[Youssef Shoaib [MOD]]

Oh yes I'm just clarifying that it's not really a "choice" per se and that it's more that depending on the consumer of your plugin, you'll have to provide something for the front-end and backend combo that they're usin

[shikasd]

Oh yes, practically you want to support both at the current stage, if possible

[Javier]

looks like it is the newest because 2127 was published 4 min earlier

[dmitriy.novozhilov]

Please use 1.7.20-dev-2106
1.7.20-dev-2127 is used for testing of gradle plugin and I didn't fully checked it

[dmitriy.novozhilov]

Corresponding commit: https://github.com/JetBrains/kotlin/commit/42df4bdda243eb643a7978d7f38ee6968cb3faa8