- Odd package names (for example `try` in `arrow-core`) were pasted
as-is to the decompiled text
- Because of this, stub checks were failing, forcing completion to start
over and over again, as if something changed in the files
- See EA-5572315 for the error
- ^KT-37144 Fixed
Also, fix the value of "hasAnnotations" flag to reflect if there are any
_non-source_ annotations on a declaration.
Unfortunately, after this change
IncrementalJsCompilerRunnerTestGenerated$PureKotlin.testAnnotations
starts to fail because of the following problem. The problem is that
annotations on property accessors are not serialized yet on JS (see
KT-14529), yet property proto message has setterFlags field which has
the hasAnnotations flag. Upon the full rebuild of the code in that test,
we correctly write hasAnnotations = true, but annotations themselves are
not serialized. After an incremental build, we deserialize property
setter descriptor, observe its Annotations object which happens to be an
instance of NonEmptyDeserializedAnnotationsWithPossibleTargets. Now,
because annotations itself are not serialized, that Annotations object
has no annotations, yet its isEmpty always returns false (see the code).
Everything worked correctly before the change because in
DescriptorSerializer.hasAnnotations, we used Annotations.isEmpty and the
result was the same in the full rebuild and in the incremental scenario.
But now we're actually loading annotations, to determine their
retention, and that's why the setterFlags are becoming different here
and the test fails
#KT-23360 Fixed
Because .kjsm files now contain all declarations from the package (contrary to
the JVM decompiler which produces one file for one class/package facade), some
common decompiled text tests started to behave differently on JVM and JS.
Update two of them (Modifiers, ClassWithClassObject) to make results the same,
copy another (TypeAliases) to JVM-/JS-specific tests with different outputs
Do not query MultifileClassCodegen#classBuilder early on: this causes the class
file for the facade to be prematurely dumped to the disk in some cases, when
that class file is not yet completely generated. Instead fork the logic in
PropertyCodegen#generateSyntheticMethodIfNeeded: save metadata in parts,
generate method in the facade
For now, JVM and JS backends produce different metadata for package facades (and package parts),
and thus different output is expected for JVM and JS decompiler.
Split decompiler tests into common (decompiledText), JVM-specific (decompiledTextJvm),
and JS-specific (decompiledTextJs)
Join them back together if JS backend migrates to JVM-like package model.
Yan Zhulanow