https://kotlinlang.org logo
Join Slack
Powered by
Is there any (recommended) way to test FIR plugins...
# compiler
y
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?
s
Maybe jetbrains have some hidden tooling to test their own plugins in Kotlin repo?
y
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
d
🙏 1
But I suggest to wait till next Wednesday, when I publish new bootstrap version of compiler It will contain some improvements to the API
y
Oooooooooo, to the FIR API in general or to the testing API specifically?
d
@shikasd it's not hidden. It is published and even documented https://github.com/JetBrains/kotlin/blob/master/compiler/test-infrastructure/ReadMe.md
Oooooooooo, to the FIR API in general or to the testing API specifically?
To the FIR API Testing API is quite stable
👀 1
s
Ohh, that's great I've been mostly working with Compose test framework, so haven't seen the newest updates
d
AFAIR we almost convinced compose team to migrate to our framework But I don't remember their final decision
z
why would a plugin choose FIR vs IR (either/or)? I think this is a bit unclear right now
j
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
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.
s
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)
z
Why would compose use FIR?
Vs IR
I didn't follow that discussion above
s
The discussion above was about Kotlin compiler test apis, I think :)
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
j
@shikasd how compose is integrated right now to show errors about it? IDE embedded plugin?
@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
Copy code
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.
s
You can write frontend plugins without fir as well, e.g. with Call/DeclarationChecker or SyntheticResolve/AnalysisHandlerExtension
y
AFAIK, AnalysisHandlerExtension only works In the current Front End (i.e. FE1.0) and won't work in FIR
s
Yep, that's how you write frontend plugins without using FIR (answer to the question above)
🙏 1
y
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
👍 1
s
Oh yes, practically you want to support both at the current stage, if possible
j
looks like it is the newest because 2127 was published 4 min earlier
d
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
98 Views
Open in Slack
Next
Powered by