Ok, so here goes very brief and incomplete descrip...

# arrow-meta

[dsavvinov]

Ok, so here goes very brief and incomplete description of how IDEA works, which you probably shouldn’t trust too much 🙂

We have two major facts to understand:

1. Compiler in CLI (in Gradle Build) is completely disconnected from Compiler in IDE. Those are two different processes, two different jars, with different way of distributing and installing them, and they have almost no synchronization. Usually, everyone thinks about them as of one entity, because people mostly advance Kotlin versions in Gradle and IDE simultaneously, thus both those “compiler” instances behave absolutely the same. Useful mental exercise here is to understand that nothing prevents you from having e.g. kotlin 1.0 compiler in CLI and Kotlin 1.3.40 plugin in IDE (and in such case, you’d obviously get quite different behaviour in CLI and IDE, e.g. if you use 1.3 features)
So, you have to put extra effort to synchronize behaviour of CLI compiler with analysis in IDE

2. During IDEA analysis, binary dependencies and sources are handled in a completely different ways. The reason is that binaries are rarely changed and have already “correct” information (e.g., there’s no sense in running inspections on binaries — if they were compiled, then they are correct). Contrary, sources are always changing and may be incorrect — during typing some incomplete constructions may arise (something like class (val x: Int) { ... }). Those sources obviously can not be compiled to bytecode, and CLI compiler would just reject them. IDE, however, is expected to provide as much insight as possible even on incorrect code, and sometimes even uses some heuristics and assumptions about “most popular cases”.
The main takeaway here is that IDEA doesn’t read compiled binaries of your source in order to provide analysis. That would make performance terrible (imagine that after adding several new lines of code you’d need to wait for recompilation of your project in order to get completion), and would prevent analysis of incomplete code (there’s no way to compile “red” code to binaries).

What does it mean for compiler plugins authors? It means that you have to ship IDEA plugin alongside with your compiler plugin if you want to see correct resolution results in IDE:
- IDEA and CLI compiler indeed share common infrastructure, especially for compiler’s frontend, but as per №1, CLI pipeline doesn’t affect IDE pipeline, so even if you use your plugin in CLI and it works, you’ll still have to bring that logic into IDE somehow
- One might be tempted to say that if CLI compiler with some plugin compiles sources fine and produces correct binaries, then IDE should just read those binaries up and provide correct analysis results. Well, as per №2 — no, that’s not how at least IDEA works, and №2 lists several reasons why. Maybe some other IDE does, but not IDEA.