Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
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
Alexey Sedunov