receiver type with modifiers or annotations should be surrounded in parentheses on rendering: '(@A R).() -> T'
This also fixes stub builder tests (which check that stubs are consistent with rendered descriptors).
(required for 'suspend' on functional types).
TYPE_REFERENCE element now has MODIFIER_LIST child, which hosts annotations and modifiers for the corresponding type reference.
Annotations and modifiers written before an extension function type are now parsed as annotations and modifiers for the functional type, not the receiver type.
So, '@Ann A.(B) -> C' was '(@Ann A).(B) -> C', and became '@Ann (A.(B) -> C)'.
NB: DSL_SCOPE_VIOLATION testData updated accordingly.
Type projection variance modifiers ('in', 'out') belong to a separate modifier list under corresponding type projection (not under a type reference).
'A<in suspend T>' is 'A<(in (suspend T))>', 'A<suspend in T>' is an error.
In stub builder, create a modifier list node to host annotations and modifiers (none so far; TODO properly serialize/deserialize types with modifiers).
Currently '()' is used for resolving ambiguity in parsing when annotating function types. This way a decompiled code
will need brackets, but compile code will have annotation without parameters. This commit will allow to make both stub-trees consistent.
Tested in ClsStubBuilderTestGenerated.testAnnotationsOnNullableTypes()
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
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
Instead of .kotlin_class and .kotlin_package files, .kotlin_builtins files are
now supported: they are decompiled to a long file consisting of all non-real
classes (those which do not also have .class files) and members in the
corresponding package.
Unlike the old files, .kotlin_builtins files have a binary version in the
beginning, which allows us to skip decompilation and stub building in case the
file has an unsupported version. This could previously lead to exceptions, see
KT-11077, EA-79339.
The change in DecompiledTextFactory is needed because without "defined in ..."
the keys for members in the long decompiled file are not unique, as there are
multiple members with exactly the same signatures in different classes (e.g.
arithmetic operations in primitive classes).
Remove testData files with the decompiled text and stubs of built-in symbols
because now that the whole package is decompiled to a single file, it would be
painful to update these files each time something in built-in sources changes
#KT-11077 Fixed
Dmitry Petrov