This commit includes three changes:
1. 'EnhancedNullability' is no more set for declaration types
2. It is no more used for conversion types in translator
3. Translator inserts implicit not-null cast only when enhanced type is cast to not-null type.
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
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 main change here is in `JvmInlineClassLowering.visitFunctionAccess`,
where we now store the substituted return type of the function as the
type of the call expression. Without it, the call could have a
meaningless type, e.g. some `T` which is inaccessible at that place, and
that could backfire in subsequent lowerings in codegen. For example, in
the `stringPlus.kt` test, it would prevent the code in
`FlattenStringConcatenationLowering.isStringPlusCall` from recognizing
and replacing the `String.plus` call, leading to a codegen exception.
Other changes are mostly cosmetics to make the code similar to
`visitFunctionReference`, and preventive optimizations for the case when
the substitution map is empty.
Arguments to function references behave the same as arguments to
function calls and should be evaluated once regardless, so the temporary
is unnecessary.
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.
Motivation:
- drop getArguments from type context as a duplicate of getArgumentList
- reduce the number of collection allocations in getAllDeeplyRelatedTypeVariables
Additional minor improvements, test data fixes
Use it to check that only the value parameters that are explicitly
marked assignable are assigned.
Currently, the only parameters marked assignable are those for
default argument stubs.
This is a follow-up to b497f39c29. It
turns out that it didn't help because `IrFunction.returnType` throws
exception, and checking for `IrUninitializedType` in `IrType.render` was
already too late. Throw and catch specific exception instead.
Also add function name into the exception message for better diagnostics
elsewhere (can't compute the full FQ name because in cases like
KT-42020, the parent is also uninitialized).
Dmitry Petrov