Anonymous types are not approximated by frontend for private declarations.
Class IDs for such types are replaced by StringTable before being written
to metadata. JVM string table mangles such types and keeps them generic
for reflection. For other purposes the types are replaced with `Any`.
Type arguments of the replaced type should be ignored in the latter case.
Otherwise decompiled text builder crashes on an attempt to restore `Any`
type with non-zero number of type arguments.
The code pretending to replace a type with its first supertype was dropped
from ApproximatingStringTable for two reasons:
- the first type from `getAllSuperClassifiers` is the original type itself
which doens't provide a ClassId for anonymous type, so it was a noop
- tracking potential type arguments of the first anonymous type's supertype
would be a complication with almost no practical value (types in decompiled
text would be slightly closer to the real type of a private declaration).
^KT-46393 Fixed
JVM tests check only single class result, in order to reuse test data
JS tests should do the same. CHECK_PACKAGE is introduced to override
this behaviour explicitly.
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
'SuspendFunction$n' class descriptors are created on demand by KotlinBuiltIns (and cached).
On serialization, types constructed with 'SuspendFunction$n' are written as 'Function$n' with extra flag (SUSPEND_TYPE).
On deserialization, corresponding 'SuspendFunction$n' classes are used.
If deserializing a type with arguments based on a local class for
decompiler, then just return Any type (without arguments).
Previously Any constructor was used with serialized arguments, that lead
to exception
Note that in case of deserialization for compiler nothing changes about
local-classes-based types (LocalClassifierResolverImpl is just inlined)
#KT-13408 Fixed
But still resolve them as annotations.
Mostly it's needed as begin of migration path, one day they become modifiers anyway
Some tests are dropped because they supposed that `annotation` should have parameter
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.
Pavel Kirpichenkov