Extract the logic that computes ACC_SYNTHETIC flag for deprecated
declarations, and use `DeprecationResolver` as the old backend does in
`DescriptorAsmUtil.getCommonCallableFlags`. Creating IR-based
descriptors for each function to pass it there is a bit costly though,
so as a small optimization, use `allOverridden` to check if anything in
the method hierarchy is deprecated.
Also optimize `allOverridden` for the case of linear inheritance which
is far more common.
#KT-43199 Fixed
When copying top level declarations from multifile parts to facades,
also copy corresponding properties. This allows to keep their
annotations, which are later used in codegen (for example, to generate
ACC_DEPRECATED on property accessors), and allows to get rid of the hack
where the JVM name of the property accessor was computed prematurely via
methodSignatureMapper.
Also, don't copy `$annotations` methods for non-const properties to
facades because the old backend only generates them in parts (which
might be a separate problem, see KT-27644).
#KT-40262 Fixed
Do not change origin of multifile class bridges to something else
because, as it turns out, there are numerous origin-specific checks in
the codegen that start to behave differently for multifile bridges.
Instead of the method-targeted origin MULTIFILE_BRIDGE, use new class
origin JVM_MULTIFILE_CLASS to detect whether a declaration is a
multifile bridge.
#KT-40198 Fixed
#KT-43145 Fixed
The old backend makes bridges for protected and package-private
methods public. Also, for bridges for vararg methods, the vararg
marker is not on the bridge.
These differences seem minor but are visible via reflection, so
we might as well follow the old backend.
This commit enables the execution of suspend box tests in a separate
test. It's a QoL improvement in the existing bb tests but, motivating
these changes, enables the new debugger stepping tests to step
coroutine code.
Types such as 'Collection<? extends CharSequence>' are treated as
'(kotlin.collections.MutableCollection<out kotlin.CharSequence!>
..kotlin.collections.Collection<kotlin.CharSequence!>?)'
by the front-end.
When generating generic signatures, JVM BE takes lower bound (which is
'kotlin.collections.MutableCollection<out kotlin.CharSequence!>').
Emulate this behavior in TypeTranslator.
In the compiler, this function was used in psi2ir (and it affected
nullability annotations in the resulting JVM class files), in "useless
elvis with null on the right side" diagnostic checker, and in light
classes.
#KT-42650 Fixed
Move collectionStubMethodLowering before jvmInlineClassPhase, and make
them interact properly.
Note that some issues still remain in inline class <-> special bridges
interaction.
KT-40187 KT-42469
The change is a bit complicated because the name mapping logic is
refactored so that we would compute the needed suffix first (either
module name, or multifile part class name), and then shove it into the
mangled name between the original function name and "$default", if the
function in question is the default arguments adapter.
The main motivation for this change was to fix KT-41809, but as a side
effect, private functions with default arguments in multifile parts now
also contain the file name, just like normal private functions.
#KT-41809 Fixed
Before this change, we stored the enclosing constructor in a map in
JvmBackendContext before moving lambdas and local classes out of
initializer blocks. However, in case the lambda was declared in an inner
class, we stored a reference to the unlowered constructor of the inner
class, whose JVM signature is "()V" instead of the correct "(LOuter;)V".
Java reflection then threw exception if we tried to call
`getEnclosingConstructor()` on such class at runtime. Proguard finished
with errors for the same reason.
It turns out that we can just store the fact that the class has been
moved, and load the matching constructor in codegen, where everything is
already lowered and guaranteed to match with the signatures of the
actual generated declarations.
#KT-41668 Fixed
Georgy Bronnikov