`KtReference` might be resolved from anywhere, even
from the write action - the call site might not know
anything about Kotlin, and might not be able to
somehow prevent the `inaccessible analysis session`
exception from being thrown. That's why we
have to be permissive here.
^KTIJ-26867 Fixed
Also adds rendering of @Metadata annotations in Kapt3 and Kapt4 tests
(currently disabled for a few tests).
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
The API replaces 'KotlinCompilerIde' in the IntelliJ IDEA plugin.
Code moved to Analysis API as its K2 implementation severely depends on
the internal compiler API (FIR).
The API is going to be used in the JVM debugger evaluator, and in
the Bytecode Tool Window.
In this commit, only ordinary Kotlin are supported.
In later commits, there will be also support for 'KtCodeFragment' files,
as well as some test coverage.
The problem results in broken import quick fix and import optimizer on
the IDE side [1].
`AssignResolutionAltererExtension` introduced a possibility to override
resolution of assignment statements. The inconsistency though is
that `KtSimpleNameReference.getResolvesByNames` doesn't return a name
for the overridden `=`. Kotlin as a language doesn't support this [2].
This commit eliminates the drawback above:
1. It fixes the name `assign` the `=` can be resolved to [3].
This eliminates the need to search for the name, bypassing the
plugins.
2. `KtSimpleNameReference.getResolvesByNames` returns `assign` among
other names in case it deals with binary `=` and assignment is
resolved.
3. `KtCompilerPluginsProvider` was extended to check plugins' presence.
K1 implementation added.
----------------------------------------------------------------
[1]: https://youtrack.jetbrains.com/issue/KTIJ-24390
[2]: OperatorConventions.getNameForOperationSymbol
https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments
[3]: OperatorConventions#ASSIGN_METHOD + AssignmentPluginNames
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Dmitrii Gridin