Here is the reasoning behind that change:
Historically, all the declarations generated by compiler plugins
were marked with `SYNTHESIZED` member kind in Kotlin Metadata
by K1 compiler.
In K1 IDE, descriptors were deserialized directly from the Kotlin
Metadata, and they saw all the generated declarations from it.
In the stubs, however, such declarations were not materialized at all.
It caused no troubles, since K1 IDE relied on descriptors to get the
essential resolution information in completion and other subsystems.
So, the resolution of members from jars processed
by compiler plugins (e.g. `kotlinx-serialization-json`) was mostly fine.
In K2 IDE, however, we use stubs to "deserialize" FIR declarations from
them, to later create `KtSymbol`s upon that FIR.
If we see a library file which was processed by compiler plugins, we
build stubs for it based on the Kotlin Metadata, and then use stubs to
create FIR.
But if stubs do not contain information about the generated
declarations,
then the resulting FIR will also not contain such declarations.
In the end, the K2 IDE would also be blind to such declarations, since
there is no other way to retrieve them from the library jar.
By meterializing all the synthethic declarations in stubs (with some
minor exceptions for data classes), we would avoid such problems,
and the resolve of such declarations from compiler jars in
K2 IDE would become possible.
Important note: currently, the Kotlin Metadata format between K1 and K2
frontends is not 100% the same; most notably, in K2, the generated
declarations are marked as regular declarations,
not as `SYNTHESIZED` ones.
Hence, if you compile a jar with the current version of K2 frontend,
then all the generated declarations would have a regular `DECLARATION`
origin, and there would be no such issues as described above.
There are two notes here:
1. K2 IDE still has to support the jars compiled by the K1 compiler,
so it still makes sense to alter the stubs and make the generated
declarations visible.
2. The issue about the different stub formats has been reported
(see KT-64924), and might be resolved in the future.
So it is possible that K2 frontend's metadata will also start
marking the generated declarations as `SYNTHESIZED`.
^KT-64808 Fixed
If an unused setter parameter was replaced with an underscore ('_'),
it had a special name in the stub ('<anonymous parameter 0>'). The text
version of the stub inserted it as is, leading to an extra
'PsiErrorElement'.
^KTIJ-28194 Fixed
We should materialize delegated declarations to process callables
in scopes correctly. Standalone mode works the same way as it
deserialize directly into FIR.
Another solution is to rework proto and stub serializer/deserializer to
restore FirFields like `$$delegate_0` correctly to work with
`FirDelegatedMemberScope`
^KT-62896 Fixed
^KT-64584 Fixed
getServiceIfCreated doesn't create a service instance if id wasn't
created before. There are no other service requests for
KotlinLabelProviderService, so it was not used for file types.
KTIJ-27755
Intercept decompiler calls to process files that belong to classpath
builtins from K2 IDE differently. Their content won't be filtered w.r.t.
JVM logic during decompilation.
Split stub versions for .kotlin_builtins with K1 and K2 IDE.
K2 currently uses a single shared symbol provider for builtins of all
platforms. KotlinBuiltInDecompiler filters out duplicated declarations
contained in JVM classfiles as required for K1. For K2 this logic
doesn't fit: non-JVM modules (common, in particular) rely on
.kotlin_builtins, because kotlin-stdlib-common doesn't contain
.kotlin_builtins or .knm files for some of the built-in declarations
(e.g., kotlin.Unit). IDE has to restore the missing declarations using
built-ins from classloader. Filtering declarations from there using K1
logic breaks resolution of these declarations inside common modules in
IDE. The change shouldn't affect JVM modules as are able to resolve
all builtin symbols from the standard library before falling back to
built-ins.
KT-61757
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
If a user has multiple kotlin-stdlib libraries in a project, all those stdlib libraries will contain builtins
which will result in resolution ambiguities.
To prevent such kind of ambiguities inside LLFirDependenciesSymbolProvider,
callables are grouped by facade class name.
Only matching callables from the first facade are used.
Facade is a Kotlin/JVM-term so right now it works only for JVM targets.
Builtins are also used in JVM, so the current solution is to have a Facade name also for builtins.
^KTIJ-26760
For some synthetic methods from compiled Kotlin classes, it is
not possible to find the PsiElement, when navigating to declaration
in the IDE.
For other methods it works like this:
1. There is a SourceElement with a psi inside
2. Or for K1, the element is searched in the decompiled text
(see ByDescriptorIndexer),
3. Or for K2, the element is searched by Stub taken from metadata
(see FirDeserializedDeclarationSourceProvider)
However, these approaches do not apply to synthetic methods which have
no SourceElement and are not written into decompiled text and metadata.
These are methods values, valueOf, entries from enum and
copy, equals, hashCode, toString from data classes.
Therefore, it was decided to handle their cases separately
at the resolve stage.
Tests (in idea repository):
- org.jetbrains.kotlin.idea.resolve.ReferenceResolveWithLibTestGenerated#testDataClassSyntheticMethods
- org.jetbrains.kotlin.idea.resolve.ReferenceResolveWithLibTestGenerated#testEnumSyntheticMethods
- org.jetbrains.kotlin.idea.fir.resolve.FirReferenceResolveWithLibTestGenerated#testDataClassSyntheticMethods
- org.jetbrains.kotlin.idea.fir.resolve.FirReferenceResolveWithLibTestGenerated#testEnumSyntheticMethods
^KTIJ-24413 Fixed
A side effect of KotlinClassFileDecompiler#KotlinDecompiledFileViewProvider@factory
that multifile java classes like FilesKt__FilePathComponentsKt.class
becomes not visible with Kotlin plugin as file
jar://..../kotlin-stdlib.jar!/kotlin/io/FilesKt__FilePathComponentsKt.class
is considered as Kotlin internal compiled file and therefore no PsiFile
for this virtualFile
#KTIJ-912
Merge-request: KT-MR-8146
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Review: https://jetbrains.team/p/kt/reviews/6753
This commit doesn't fix any issue except for "cleanup". If you find a
mistake in this commit feel free to revert part of it/the whole commit
I checked every module where I drop ':dist' dependency. Tests still pass
in those modules
Marco Pennekamp