- This improves the memory usage of `FileStructureElementDiagnosticList`
by avoiding lots of duplicate empty mutable maps. We can assume that
most diagnostics lists are empty, since code is usually green.
- I tested the memory consumption manually by opening all files in
`org.jetbrains.kotlin.idea.k2.codeinsight.inspections` and waiting for
analysis to finish for each file. With the change, the retained size
of `FileStructureElementDiagnosticList` shrank from 63.39kB to
13.77kB.
It is duplicated because we have two checkers: FIR (for IDE support
in simple cases) and IR ("honest" checker supporting all cases).
Fix this by running FIR checker only in IDE.
FIR checker behavior remains covered by tests in
`LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated`.
^KT-62559 Fixed
When flattening a dependency FirSymbolProvider, make sure transitive
dependency FirSymbolProviders are not included. This requires checking
that nested symbol provider sessions match the composite symbol provider
session when they are both source sessions.
^KT-60614 Fixed
Without it, the lazy body of code fragment is not properly resolved
and cannot be analyzed
Use the correct function from `BodyResolveContext` to take the scopes
from code fragment into account
^KTIJ-27879 Fixed
In the IR generator, we had a so-called `ConfigModel` with classes like
`ElementConfig` and `FieldConfig` that we deal with during
tree configuration in `IrTree.kt`, and another kind of model called
just `Model` that included the `Element` and `Field` classes
correspondingly. Those were used for actual code generation.
After configuration, `ConfigModel` was transformed to `Model` and
then the code generation was performed using `Model`.
This architecture is overly complicated and results in massive code
duplication. Most `ElementConfig` and `FieldConfig` properties had
exactly the same counterparts in `Element` in `Field` classes.
So, if you wanted to add a new feature to the tree generator, you had to
add a property to both `ConfigModel` and `Model`.
Turns out we can do just fine with only one kind of model.
Since JDK 17+ pretty-printer does not print parens on empty annotation
parameters, print them anyway. Otherwise, tests with annotations differ
on different JDKs.
#KT-57389
Previously, some tests have also been disabled on JDK 11+, since
we did not filter out empty filesets, which led to failed assertion
inside JDK.
#KT-57389
This is the case when we have Java class in hierarchy. In this case,
we want to generate reflective access to the original Java method.
#KT-63642 Fixed
When compiling code fragment, we forbid to use `irLinker` as
IR provider. Because of that, if there are some plugin
extensions, we will not be able to find deserializer
for a given module and will fail.
#KT-63695 Fixed
As a file annotation container is required for resolution,
it should be closer to the resolution logic. Now only LLFirTargetResolver
will operate this logic, so we can change the logic in the future without
a big refactoring.
E.g., as the next step, this resolution can be integrated to the file
^KT-63042
This entry point is required to be able to pre-resolve dependency
declarations.
E.g., fake override declaration shares annotation instances between
the original and the fake one, so we should resolve the original
firstly to avoid concurrent modification and correct context.
This will be done later.
This commit effectively only drops body resolution for a file annotation
container if the target element is not a file because this
is not required for correct resolution
^KT-63042
Svyatoslav Kuzmich