Hello, what would be the advantages/disadvantages ...

# compiler

[Waldemar Kornewald]

Hello, what would be the advantages/disadvantages of the analysis API vs. a FIR compiler plugin for some static code checks?
Wouldn't a FIR checker plugin minimize the CI run times because it runs directly with the compilation while AA requires an additional parse/analysis step?
Also, as-you-type checks would only be possible with a FIR plugin, right (unless everyone on the team installs an IDE plugin)?
AA has a more stable API, but let's pretend that doesn't matter so much in this case.
Does AA just provide a more high-level / convenient API than FIR or would the checks have similar complexity in both?

As a more extreme example, wouldn't a detekt-like FIR (maybe +IR) compiler plugin provide a better user experience since all checks would be visible on-the-fly in the IDE? Or would such a plugin cause too much overhead because it has maybe 200 checks that run all the time while typing?

[dmitriy.novozhilov]

AFAIR standalone analysis API doesn't provide access to bodies, so detekt-like inspections are impossible to implement with it. You could write an IDE plugin and use AA to get the resolve information in the same way as Kotlin IDE plugin does for inspections. The same plugin could be run on CI using Qodana.

Wouldn't a FIR checker plugin minimize the CI run times because it runs directly with the compilation while AA requires an additional parse/analysis step?

That's correct, the plugin is the fastest option.

Does AA just provide a more high-level / convenient API than FIR or would the checks have similar complexity in both?

The API of AA and FIR are quite similar. Keep in mind that AA symbols is just a wrapper over the FIR declarations. But again, with AA you cannot write body checkers in vacuum.

As a more extreme example, wouldn't a detekt-like FIR (maybe +IR) compiler plugin provide a better user experience since all checks would be visible on-the-fly in the IDE? Or would such a plugin cause too much overhead because it has maybe 200 checks that run all the time while typing?

It depends on how fast/slow these checks are. The compiler itself has about 200-300 hundred checkers, and some of them do quite non-trivial job, but the IDE experience is acceptable.

But if you go with IDE integration, then the plugin compatibility is the issue. Compiler version used by IDE for analysis never matches none of released compilers, and you most likely will experience compatibility problems all the time, unless you compile your plugin specially for the each IDE version you want to support (check messages in the channel, it's quite a hot topic).

[dmitriy.novozhilov]

Generally I would say that detekt seems to me the best option. Yes, it would be slower than compiler plugin, but it's stable and has builtin IDE integration, so it will have the least maintenance cost

[Waldemar Kornewald]

Thank you. That's some important problem to think of...though compiling for multiple IDE versions might be an option.

AFAIR standalone analysis API doesn't provide access to bodies, so detekt-like inspections are impossible to implement with it. You could write an IDE plugin and use AA to get the resolve information in the same way as Kotlin IDE plugin does for inspections. The same plugin could be run on CI using Qodana.

Isn't detekt currently migrating to use the new analysis API? Does that mean they might not be able to implement all their inspections? Or is that not an actual problem if they integrate the compiler like KSP2 does?

[dmitriy.novozhilov]

I don't know anything about detekt implementation details, sorry