There's been lots of chat about FIR in the context of plugins and the within the compiler, but are there any examples of setting up FIR in a standalone project to interpret parsed Kotlin? I'm currently doing this with PSI and it's a huge pain because I don't actually care about the precise syntax tree but just want to parse a semantic tree (similar to what runtime reflection would provide).

There is no such standalone tool yet But you can create FIR plugin with additional file checker and introspect resolved files in this checker

I found

compileModuleToAnalyzedFir

which might be exaclty what I want. So I think I can walk myself backwards towards the

KotlinCoreEnvironment

/

CompilerConfiguration

/

VirtualFileManager

/ etc. that I already have setup for PSI.

Yeah, this approach will work too

it's working! SO much nicer than dealing with PSI. It's like night and day.

Curious what youre working on here that you want to interpret FIR 👀

We use Kotlin as a schema language to define sets of types and properties within those types to perform code generation of other things. For the past two years I've been using reflection, but we lose two very important things: comments and default expressions. For defaults I've just been forcing people to put a string in an annotation that I read. Haven't had a solution for comments. So I always knew that I would be switching to UAST/PSI, but it is so unpleasant to parse at that layer because it's basically just a lexer/parser. Getting out something usable (especially in comparison to reflection) involves so much error/unexpected handling. So FIR gives me higher level constructs closer to reflection-level and also handles linking of types.

Is it worth it for projects like detekt (where a compiler plugin seems to be the future) and ktlint (where there don't seem to be any plans to use a compiler plugin) to switch over to using FIR? Using UAST/PSI has always been a drag for me when reading/contributing rules, but I'm assuming it would be a pretty big migration?

Well ktlint cares about formatting so they'd need to stick to PSI

Would it be a bad idea to try and write out the formatted code by mapping FIR to source code instead of modifying the existing code?

It's not easy to map FIR back to source code FIR is a semantic tree, so it doesn't store any information about syntax aspects, like parenthesis or linebreaks Also it performs some desugarings, so you will be forced to undo them back (e.g. there is no if in FIR tree, only when) The only thing FIR knows about the syntax is the links to original PSI elements (to properly report diagnostics), but the mapping is not full (some PSI nodes are missing, and some were duplicated)

Ok so wouldn't be useful for tools like ktlint, but for something like detekt rules that check behavior instead of syntax it could be useful.

Yeah, probably But there is a cumbersome question about API stability. At this moment we are struggling to make stable API for just declarations. And API of body content much larger and has more chances to change with bugfixing, performance improvement of new language features So tools which rely on it will suffer a lot (like all IR plugins right now)

Stability will come with 2.0 or after it?

After Main goal for 2.0 is enabling FIR by default in all scenarios

Just curious, are comments even reference-able by using psi or are they dropped during parsing (

ParserDefinition.getCommentTokens

)? I had the same problem with my own compiler (a COBOL to Kotlin converter), and decided to add the comments to the actual language to keep the comments used by the Kotlin code generator.

They should be referencable, because compiler looks for kdoc comments on IR stage in some cases

But not inline comments, should it?

I never checked, actually But most likely they also should be saved

How does that compare to stability of PSI? I have a side project that involves something like PsiMiner

FIR doesn't have comments but it has originating PSI elements where you can drop down and read the precise syntax tree