1. Use 'x' for each parameter, which is not an inline class, every
possible clash is handled by signature rather than name. This change
makes more API changes binary-compatible. So, the changes are in line
with the vision of inline classes are value classes, like primitives.
2. Take return type into account when mangling a function if the return
type is inline class. Otherwise, boxing bridge will not be generated,
which leads to CCE at runtime.
Do not destructively update the @JvmStatic function, instead
create a copy on first access, and replace the original with
the copy in the jvm static lowering. This ensures that the original
function is seen in other lowerings independently of file lowering
order.
In particular, `@Deprecated` is not lost anymore and accessors of
deprecated property are generated with ACC_DEPRECATED just as in the old
backend.
#KT-43327 Fixed
When calling vararg methods with a generic vararg type without
passing explicit parameters, we have to allocate an empty array
of the right type. We failed to do so previously, as we did
not take the type arguments for the dispatch receiver into
account.
If it isn't ANNOTATION_CLASS, the newly added code in
`FunctionCodegen.isDeprecatedHidden` (0e91d3fcb0) ends up transforming
IR annotation constructor calls to annotation descriptors, and an
assertion fails in `IrBasedDeclarationDescriptor.toAnnotationDescriptor`
which checks that the class has kind ANNOTATION_CLASS.
Specifically, this failed in the JVM IR bootstrap on
`CallResolutionInterceptorExtension.interceptCandidates` from module
'frontend'.
The current implementation doesn't consider Foo a subtype of Captured<in
Foo>!!, since AbstractTypeCheckerContext::checkSubtypeForSpecialCases
does not handle DefinitelyNotNullType cases. This PR adds handling of
DefinitelyNotNullType by looking at its original type.
^KT-42824 Fixed
The issue is the type checker doesn't consider P? a subtype of
CapturedType<in P>?, whereas P a subtype of CapturedType<in P>?. In
AbstractTypeCheckerContext::checkSubtypeForSpecialCases, it checks if
P? is a subtype of the lower type of the captured type, which is
P, and returns false.
This fix uses nullable version of the lower type when the captured
type is marked nullable. To check if P? is a subtype of Captured<in
P>?, we check the LHS, P?, against the nullable lower type of RHS,
P?.
^KT-42825 Fixed
In the old backend, BindingContextSuppressCache is used (which is now
created explicitly in GenerationState), which looks up `@Suppress`
annotations on elements right before reporting the diagnostic. In JVM
IR, we clear the binding context after psi2ir, so this approach doesn't
work. This change provides another implementation of KotlinSuppressCache
which eagerly precomputes all suppressions on all annotated elements in
all source files at the point of creation of GenerationState (when the
binding context is still full).
#KT-43047 Fixed
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.
Ilmir Usmanov