Use existing stub-based JVM library symbol provider for .knm and
.kotlin_metadata files. The only real difference is the scope filtering
by file types
KT-58769
- A proper merging strategy for declaration providers is required for
cases where the main declaration provider created by
`createDeclarationProvider` can't provide all declarations that the
original declaration providers can provide. Then, only a sublist of
the declaration providers should be merged, while keeping the
unmergeable declaration providers intact.
^KT-58580 fixed
this gives the following benefits:
1. no protobuf in memory, all data is already present in stubs
2. given that symbol provider for libraries is already stub based,
we can get rid of complicated code to find source psi by deserialized fir
3. it's also possible to reduce number of index access,
when fir is requested for given ktElement
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
- In performance tests, modification trackers were incorrectly
incremented between tests for binary modules even with library caches
enabled. The new option `includeBinaryTrackers` can be used by
performance tests to exclude binary modules.
Previously, we queried heavy kotlin package provider two times which affected performance
Now it's being queries only a single time
Also, the commit introduces separation for KotlinPackageProvider between kotlin and platform-specific packages
^KTIJ-24640
Pavel Kirpichenkov