To make these tests behave closer to kapt, since kapt is the primary use
case for the light analysis mode.
AbstractLightAnalysisModeTest compares the text dump of bytecode
obtained with full analysis and light analysis, removing things like
anonymous/synthetic entities. In the light analysis mode anonymous
objects in supertypes are always approximated, and in the full analysis
mode they are always present as is in signatures. So we're transforming
the text dump in the same way, by approximating anonymous objects in
signatures (more precisely, in return types of methods and fields) to
the supertype.
This is needed in order to run light analysis mode tests for JVM IR
backend. In the subsequent commit, this extension is added to light
analysis mode tests.
Kapt stub generation uses this extension to transform local types to
non-local:
private val x = object {}
With this extension, x's type will be `Any`. Without it, it will be an
anonymous type. This anonymous type was not a problem for the old JVM
backend, but it's difficult to translate it in the IR infrastructure in
the light analysis mode where bodies are not resolved.
When kapt stub generation works with JVM IR enabled,
KaptAnonymousTypeTransformer ensured that backend would not crash and
stubs would contain something useful.
However, this is not happening in light analysis mode tests, which are
supposed to check how compiler behaves in the light analysis mode which
is used in kapt.
This is not a user-visible change, so no issue is created and no tests
are added.
K1 uses angle brackets, and it will be very convenient to have the same
module names in K1 and K2, in particular to compare IR dumps where
almost everything is the same (up to a certain point) except the module
name.
In kapt stub generation mode, psi2ir does not generate bodies of
declarations. This means that the delegate type was translated into an
IrType which is based on a class which is not generated by psi2ir, thus
leading to an unbound symbol error. The fix is to avoid using anonymous
types for delegate fields in this mode.
#KT-59211 Fixed
Relates #KT-57647
If a serialization descriptor is used in the companion, then when accessing the child elements, an array of cached child serializers may be read.
Since the serialization plugin adds its declarations to the class after the declarations from the source code, the initialization of the array of child serializers occurs after the execution of the user code.
This can lead to N PE errors when trying to access an unfilled cached child serializer.
The solution is to change the order of declarations so that the declaration with the property of cached child serializers comes first.
Merge-request: KT-MR-10545
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Still supported IDEA/Kotlin plugin releases relies on
'kotlin-annotation-processing-gradle' artifact name in compiler plugins
classpath. I've restored this publication usage until we will stop
support Kotlin plugin versions that doesn't know about
'kotlin-annotation-processing-embeddable' name.
^KTIJ-25586 Fixed
Kotlin 1.7.20 added optimizations for delegated properties on the JVM,
which broke serialization for optimized properties. Commit bfeff81
tried to fix that, but broke non-optimized delegated properties. This
commit restores correct serialization for optimized and non-optimized
properties, also ensuring that it only affects the JVM target.
#KT-58954 Fixed
#KT-59113 Fixed
IDEA projects may have duplicate dependencies on kotlin stdlib. In that case, `IrPluginContext.referenceFunctions` may return more than one copy of each standard function, including three overloads of `kotlin.lazy`. And here's when serialization plugin may fail with an exception.
It affects Kotlin debugger -- if such a project or module also has serialization plugin enabled, then it completely breaks new evaluation, meaning it's impossible to compute any expression.
Fixes IDEA-314785
Merge-request: KT-MR-10262
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
This only applies to JVM and fq-names in declaration references
in IR dumps.
This enables us to run more irText tests on platforms other than JVM
(see KT-58605).
Fixes #KT-58918
If the serializable class contains itself as a generic parameter of the property, and its serializer is not an object (for example, for a sealed class), in this case there is a race in the initialization of the serializer and child serializers.
Merge-request: KT-MR-10363
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
Prior to this commit code completion for .kts files was supported only
partially. Script has an implicit receiver - base class representing a
script itself, the point where its basic API resides. The knowledge of
this receiver was missing.
There are at least two context where this knowledge is crucial:
1. Code highlighting (worked fine)
2. Code completion (failed)
`FirScriptConfiguratorExtension` is responsible for filling
`FirScriptBuilder` with base script class (in addition to other
properties). See usages of [1] in its implementation.
The thing is that resolution during the completion works a bit
different. Instead of converting the entire `KtFile` it's interested
in `KtScript` only. See usages of [2].
`RawFirBuilder.Visitor.visitScript` is where implicit receivers were
missing.
Code completion and inspections applied to `.kts` files already have
`FirScript` and don't require its full reconstruction with expensive
`FirScriptConfiguratorExtension`. `RawFirBuilder.Visitor` was modified
to support sometimes already existing `FirElement`.
----------------------------------------------------------------
[1]: ScriptCompilationConfiguration.baseClass
[2]: RawFirBuilder.Visitor.convertScript
To be reported with [1] imports require source. It was missing for
implicit script imports.
`FirScriptConfiguratorExtensionImpl` was extended and now adds fake
source elements (users don't see imports in the source code).
Since diagnostics for implicit import statements are meaningless for
IDE, they are suppressed in `LLFirDiagnosticReporter`.
----------------------------------------------------------------------
[1]: DiagnosticReporter.reportOn()
The following two registrars were missing:
- FirScriptingCompilerExtensionIdeRegistrar
- FirScriptingSamWithReceiverExtensionRegistrar
`FirScriptingCompilerExtensionIdeRegistrar` was introduced as a copy of
`FirScriptingCompilerExtensionRegistrar` adapted for usage from IDE.
`FirRegisteredPluginAnnotations` and `FirJvmTypeMapper` are mandatory at
`FirExtensionService.registerExtensions` and reported as missing at
runtime.
Default imports coming from script configuration can be of "star" type.
Prior to this commit they were effectively ignored due to a bug at FQN
assembly.
Before: org.gradle.dsl.* => org.gradle.dsl.
After: org.gradle.dsl.* => org.gradle.dsl
Pinning the language version is rarely the right thing to do.
This changes makes it harder to do so by requiring an additional
directive with a name that indicates to developers that they are
likely doing something dangerous.
For Compose libraries, it is important that libraries built with
K2 in version 2.0 can be read and used by a version 1.9 K1
compiler. That is not possible if custom function types are
in the metadata.
^KT-58456 Fixed
With this change it will have consistent naming with other compiler plugins.
'-embeddable' was also renamed.
'dist' should contain two identical jar files:
- 'serialization-compiler-plugin.jar'
- 'kotlinx-serialization-compiler-plugin.jar'
^KT-58530 In Progress
Sergej Jaskiewicz