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

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

To the FIR API Testing API is quite stable

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.

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.

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.

Vs IR

I didn't follow that discussion above

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

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

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