Commit Graph

18 Commits

Author SHA1 Message Date
Roman Golyshev 47aa6392bf KT-64808 [stubs] Materialize all synthethic declarations in Kotlin Stubs
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
2024-02-23 10:51:28 +00:00
Dmitriy Novozhilov a43cb721ba [FE] Convert ClassId.java to Kotlin 2023-09-21 12:40:43 +00:00
Vladimir Dolzhenko 37c493f593 Add missed DOT_DEFAULT_EXTENSION
#KTIJ-25470
2023-05-17 12:45:19 +00:00
Anna Kozlova 7ee648a4f5 [cls] include annotation arguments in cls stubs
^ KTIJ-24666
this would allow to build fir based on stubs,
do not keep ProtoBuf in memory and
search in decompiled code by stubs
2023-04-26 21:43:15 +02:00
Anna Kozlova 4fe239375f [cls] write contracts information to cls stubs
^ KTIJ-24665
this information would be used to create resolved FirElements from stubs,
so no ProtoBuf would be kept in memory
2023-04-25 08:34:18 +00:00
Ivan Kochurkin e22359cc10 [FIR] Add MetadataSymbolProvider
Extract common code from K1 to MetadataUtil
2023-01-24 15:27:12 +00:00
Ivan Kochurkin 3f68694b0f Move MetadataPartProvider to deserialization.common
To make it possible to use it in FIR compiler
2023-01-24 15:27:11 +00:00
Pavel Kunyavskiy 17e9a6a781 [klib] Fix serialization of missing annotations
^KT-42490
^KT-44625
2022-12-20 20:06:51 +00:00
pyos 456fe858a0 FE: commonize logic for value class representation building 2022-11-10 22:12:08 +00:00
Abduqodiri Qurbonzoda 34e50649e8 Switch JVM target of the standard libraries to 1.8 #KT-51907 2022-08-13 01:33:45 +03:00
Yahor Berdnikau af6f17c243 Unify kotlinCompilerClasspath for all projects
This will prevent spawning second Kotlin daemon during compilation
except 'buildSrc' compilation. Original change was introduced in
2e515f3945 commit.
2022-05-24 07:58:38 +00:00
Alexander Udalov 2e515f3945 Prohibit JVM target 1.6
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.

 #KT-45165 Fixed
2022-04-19 22:54:40 +02:00
Ilya Kirillov 3686fc109d Extract AnnotationLoader from AnnotationAndConstantLoader, so it can be used without FE1.0 2021-12-27 16:23:07 +03:00
Alexander Udalov 0a9498f7e2 Build: suppress deprecated JVM target warning globally
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.

Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
2021-07-27 13:35:39 +02:00
Yahor Berdnikau 7789054547 Migrate repo to use JVM toolchains Gradle feature.
^KT-46972 Fixed
2021-07-05 14:11:12 +00:00
Alexander Udalov e0b6d4d917 Add -Xsuppress-deprecated-jvm-target-warning to modules compiled with 1.6
Currently this leads to an unknown argument warning, but it'll be
removed automatically on the next bootstrap.
2021-02-03 12:51:39 +01:00
Dmitriy Novozhilov 36d2129fd3 Move common deserialization classes from :core:metadata modules 2020-09-11 10:08:37 +03:00
Dmitriy Novozhilov 07a3009d43 Introduce new modules for common parts of deserialization 2020-09-11 10:08:37 +03:00