https://kotlinlang.org logo
y

Youssef Shoaib [MOD]

06/10/2022, 3:00 PM
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

shikasd

06/10/2022, 3:09 PM
Maybe jetbrains have some hidden tooling to test their own plugins in Kotlin repo?
y

Youssef Shoaib [MOD]

06/10/2022, 3:12 PM
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

dmitriy.novozhilov

06/10/2022, 3:14 PM
🙏 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

Youssef Shoaib [MOD]

06/10/2022, 3:32 PM
Oooooooooo, to the FIR API in general or to the testing API specifically?
d

dmitriy.novozhilov

06/10/2022, 3:32 PM
@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

shikasd

06/10/2022, 4:04 PM
Ohh, that's great I've been mostly working with Compose test framework, so haven't seen the newest updates
d

dmitriy.novozhilov

06/10/2022, 4:11 PM
AFAIR we almost convinced compose team to migrate to our framework But I don't remember their final decision
z

Zac Sweers

06/10/2022, 6:38 PM
why would a plugin choose FIR vs IR (either/or)? I think this is a bit unclear right now
j

Javier

06/10/2022, 7:07 PM
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

shikasd

06/10/2022, 10:19 PM
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

Zac Sweers

06/10/2022, 10:23 PM
Why would compose use FIR?
Vs IR
I didn't follow that discussion above
s

shikasd

06/10/2022, 10:24 PM
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

Javier

06/11/2022, 12:10 AM
@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

shikasd

06/11/2022, 1:37 PM
You can write frontend plugins without fir as well, e.g. with Call/DeclarationChecker or SyntheticResolve/AnalysisHandlerExtension
y

Youssef Shoaib [MOD]

06/11/2022, 1:57 PM
AFAIK, AnalysisHandlerExtension only works In the current Front End (i.e. FE1.0) and won't work in FIR
s

shikasd

06/11/2022, 2:01 PM
Yep, that's how you write frontend plugins without using FIR (answer to the question above)
🙏 1
y

Youssef Shoaib [MOD]

06/11/2022, 2:03 PM
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

shikasd

06/11/2022, 2:04 PM
Oh yes, practically you want to support both at the current stage, if possible
j

Javier

06/15/2022, 7:11 PM
looks like it is the newest because 2127 was published 4 min earlier
d

dmitriy.novozhilov

06/15/2022, 8:01 PM
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
14 Views