Upgrade Kotlin and arrow to 2.x series

[raulraja]

First step to get arrow-analysis updated and wired with FIR.

Most relevant changes are in IrSyntax and toml file, the rest are the new spotless requirements.

[apatrida]

@raulraja will this get into a release soon, or only after analysis also updated?

[raulraja]

@raulraja will this get into a release soon, or only after analysis also updated?

Hi @apatrida!. I'm not sure, I did this as first step to try to update analysis to latest Kotlin version but I'm not sure what the next step forward should be, if we should release or rewrite the entire arrow-meta library. Here are some thoughts about the issue.

1. Legacy Frontend and FIR Transition

• The old non-FIR Kotlin frontend is still available in Kotlin, but maybe will be removed soon once K2 and FIR are the default?, half of arrow-meta is that.
• Should Arrow Meta completely drop support for the legacy frontend?
• If we remove it, the only remaining major component would be the IR Generation Extension.
• Currently, Arrow Meta has no integrations for FIR. I'm considering re-encoding it entirely for FIR and IR, but FIR’s limited transformation and generation capabilities make this challenging.

2. Avoiding Compiler API Exposure in Meta

• Exposing Kotlin's compiler APIs in Meta introduces dependency conflicts, especially with PSI differences across compiler versions even if you depend on the embedded compiler, part of the PSI layer is embedded in the compiler and exposed in different packages if you depend in the regular compiler vs the embedded one.
• Ideally, we should operate at a higher level, similar to how we prototyped Arrow Reflection, allowing:
  • Macros
  • AST transformations
• However, FIR does not allow AST transformers and keeps them internal for their own use. This blocks us from achieving a macro-like syntax in Kotlin.
• I'm currently hacking a checkers transformation and frontend compilation phase in Arrow Reflection to work around this:
  • [Arrow Reflection - Template Compiler](https://github.com/arrow-kt/arrow-reflection/blob/main/arrow-reflect-annotations/src/main/kotlin/arrow/meta/TemplateCompiler.kt)

3. Rethinking Kotlin Meta-Programming

If FIR is here to stay, should we redefine what Arrow Meta should be? Some key ideas for a revamped meta-programming library:

• Compiler Pipeline DSL:

  • Avoid exposing low-level compiler types like we currently do in [Arrow Analysis](https://github.com/arrow-kt/arrow-analysis/tree/main/analysis/common/src/main/kotlin/arrow/meta/plugins/analysis/phases/analysis/solver/ast/context).

• Macro-like Features:

  • Support annotation-based or procedural macros that work at both declaration and expression levels—similar to what we prototyped in [Arrow Reflection](https://github.com/arrow-kt/arrow-reflection/blob/main/arrow-reflect-annotations/src/main/kotlin/arrow/meta/samples/Increment.kt).
  • Consider alternative macro syntaxes, inspired by Rust or other macro-friendly languages.

I'm in favor to through away arrow-meta and start fresh with a new approach, but we still have those compiler hacks to deal with unless Kotlin decides to expose the FirTransfomer. AFAIK only the Fir status transformer is the only one exposed to plugins.

A question for @serras and @demiurg906 . Since they work with the Kotlin compiler and language design. Where does Kotlin stand in terms of meta-programming? Any plans or thoughts in opening up in FIR FirTransformer AST transformations for plugins?

[demiurg906]

Where does Kotlin stand in terms of meta-programming?

In between "no meta-programming at all" and "arbitrary macros-like transformations". We are satisfied with current possibilities provided by the plungin API, and there are no plans to extend them, only stabilize.

Any plans or thoughts in opening up in FIR FirTransformer AST transformations for plugins?

Most likely it would be never done. With such common API for transformations it would be impossible to provide the proper out of box IDE support and incremental compilation for any compiler plugin.