Hello! I'm working on moving detekt from using PSI...

# compiler

[Brais Gabin]

Hello! I'm working on moving detekt from using PSI to FIR. This is a huge change for us because we have references of KtFile and KtElement all over the place. For that reason I'm looking for a way to start using FIR but be able to fallback to PSI when needed and then keep refactoring removing those fallbacks until we only use FIR. I'm using this code: https://gist.github.com/handstandsam/9a561fc78b593039d1dd500fae14b355 to get a List<FirFile> and then convert those to `KtFile`s using firFile.psi!! as KtFile (https://github.com/detekt/detekt/pull/7406/files). The problem is that firFile.psi always return null. I saw that the source that I'm getting is a KtLightSourceElement instead of a KtPsiSourceElement that will make psi to return a not-null value. How can I accomplish this? Does it even have sense the approach that I'm taking to move to FIR?

[dmitriy.novozhilov]

You need to pass -Xuse-fir-lt=false to enable PSI parser instead of LT parser
If you are setting up the CompilerConfiguration manually, you need to set CommonConfigurationKeys.USE_LIGHT_TREE to false

[Brais Gabin]

Thanks for the answer! I added configuration.put(CommonConfigurationKeys.USE_LIGHT_TREE, false) but it doesn't change anything. Looking at the code I see that compileModuleToAnalyzedFir calls unconditionally to buildResolveAndCheckFirViaLightTree.

[dmitriy.novozhilov]

There is a FirKotlinToJvmBytecodeCompiler.compileModulesUsingFrontendIRAndPsi
source

[Brais Gabin]

I made it work creating my own FirKotlinToJvmBytecodeCompiler.FrontendContext and then calling to runFrontend. Well, "working" I still have lots of things to figure it out but at least I get a list of `FirFile`s with working psi property. Thanks!

[dmitriy.novozhilov]

Do I understand correctly that detekt uses the compiler to get some resolve information, like types or resolved symbols?
If so, I think the better approach to use Standalone Analysis API instead of FIR directly
AA is a special layer between compiler and external tools (like Intellij Kotlin plugin or KSP) which has stable API surface (well not right now, but it is actively stabilized)
And also it works with PSI by default

Here you can find some documentation about it

[Brais Gabin]

Do I understand correctly that detekt uses the compiler to get some resolve information, like types or resolved symbols?

Yes, you understand it correctly. Thanks! To be honest I started yesterday and I'm doing just proves of concept to look which is the better way to take. I'm going to check to that documentation that you link 🙂