This allows to get rid of the situation where a JvmStatic function in
object can be seen in different states in different lowerings: unlowered
with a dispatch receiver parameter, declaration is lowered but calls are
not, and both declaration and calls are lowered.
Now it works like this:
1) JvmStatic functions in objects coming from dependencies are always
loaded as lowered, without the extra dispatch receiver parameter. In
psi2ir this is done via JVM-specific extension; in fir2ir it's done
in place (but probably should be extracted to extension too).
2) Functions from sources are created as unlowered by both psi2ir and
fir2ir, and are lowered in a module-wide phase at the beginning of
JvmLower.
3) Calls to all JvmStatic functions from objects (from sources and
dependencies) are lowered in the same phase at the beginning of
JvmLower.
This ensures that all lowerings after the module-wide phase
`jvmStaticInObjectPhase`, which include all per-file phases, see all
JvmStatic functions in objects without the additional dispatch receiver
parameter, and calls do not have dispatch receiver either.
The only issue with this approach is that function/property reference
representation in reflection needs to have that dispatch receiver
parameter, and that is achieved via a hack in those lowerings, which
seems not too out of place anyway, given that they're handled specially
in kotlin-reflect as well.
because some other compiler plugins (Compose) copy/rewrite IR declarations
completely, and in the end, functions that are present in the final IR tree
do not have bodies.
Correctly create IrProperty and IrField when they were absent from the
descriptors (in case for private serializer properties)
Do not use symbol table because 'declare' API is not available in plugins.
Fixes https://github.com/JetBrains/compose-jb/issues/46
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.
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.
Zalim Bashorov