What does Fir stand for in Kotlin compiler?

# compiler

[Imran/Malic]

What does Fir stand for in Kotlin compiler?

[karelpeeters]

Frontend Intermediate Representation: https://youtrack.jetbrains.com/issue/KT-31265

[Imran/Malic]

Is there an Asm Codegenerator where we can transform TreeElements such as Class etc?
Similiar to this https://github.com/JetBrains/kotlin/blob/37b1c175ce3a8ac0fef045f34d95dac088b999ec/compiler/ir/ir.tree/src/org/jetbrains/kotlin/ir/visitors/IrElementVisitor.kt#L23

[Imran/Malic]

I am always hitting a wall looking for the right backend😅

[Imran/Malic]

Sorry @karelpeeters for the formulation. I hope it doesnt sound demanding 😅

[karelpeeters]

Yeah no problem, but I don't have an answer simple smile . I just remember it from this thread: https://kotlinlang.slack.com/archives/C7L3JB43G/p1565472455032800

[Imran/Malic]

Thank you @karelpeeters any help is welcome. 🙂

[raulraja]

FIR is an experimental frontend that is currently in development

[Imran/Malic]

Thank you @raulraja 🙂

[wasyl]

Maybe stupid question, but what’s frontend in the context of a compiler?

[Imran/Malic]

AFAIK Frontend usually refers to typechecking, resolution and parsing. There might be more what is done in frontend, but in contrast to that backend deals with MaschinCode in multiple platforms as we have it in Kotlin. Please take this with a grain of salt I am still learning 🙂

[wasyl]

Do I understand correctly that Jetpack Compose needs this intermediate representation to perform manipulations on it and pass further? Because that’d be the natural place to perform rewrites of the code into whatever structure Compose needs?

How does it compare to coroutines — where does this rewrite take place, since Fir is not yet released?

[raulraja]

All plugins but arrow meta use the codegen phases whether it's IR or ASM for the JVM because the current PSI tree in the CLI compiler can't be mutated unless you are in the IDE. This has been my findings but also take this with a grain of salt. There are no docs

[raulraja]

Meta is able though to mutate that tree internal document to transform the tree prior to resolution which is where descriptors and types are associated before codegen

[raulraja]

In addition Jetpack compose uses a fork of the Kotlin compiler with new extension points that I heard they are planning to contribute upstream to the Kotlin compiler

[raulraja]

But you can't rely on what jetpack compose is doing as they have other extensions all other plugins have no access to

[Imran/Malic]

@raulraja Does that mean whenever we manipulate the PSI tree for instance with a KTVisitor we change it in the editor but not in CLI?

[raulraja]

KtElements in the CLI compiler are immutable because the CLI compiler lacks de copyElement extension required to mutate the tree. That is only available in the IDE plugins.

[jereksel]

There seems to be some kind of FIR plugin API: https://github.com/JetBrains/kotlin/tree/1.4-M3/plugins/fir/fir-plugin-prototype

[jereksel]

I'm lost if I should choose IR or FIR for my plugin - I can't any information what are the specific differences and use cases.

[raulraja]

FIR is supposed to replace the current frontend or parts of it AFAIK but not sure if it’s in stable place to develop plugins, if it is I’d also love to know. Maybe @dmitriy.novozhilov can provide some insight as to the status of FIR and if we should start looking into it for plugins.

[dmitriy.novozhilov]

Hello, @jereksel
As @raulraja said before, FIR is active development stage and it's far way from being production ready. API by the link you get is our PoC prototype for compiler API, it's not tested properly and it definitely will change in future.
So, if you want to create compiler plugin right now, then you should use IR extension points for generating new code and transforming existing

[dmitriy.novozhilov]

Currently compiler API is not our main goal, so FIR compiler API won't be stabilized soon