They are currently marked as defined even when they get a
default implementation. That makes it hard to figure out
if the accessor should be removed when introducing a backing
field in the JVM_IR backend.
Preserve type substitution:
- when obtaining function type for SAM type;
- when generating SAM conversions for SAM adapter arguments;
- for "original" method corresponding to a SAM adapter.
```
fun <T : Any> CHECK_NOT_NULL(x: T?): x =
if (x != null) x else throw NullPointerException(...)
```
This allows to compile both Kotlin/JVM and Kotlin/JS effectively.
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
This is actually either a LAMBDA or an ANONYMOUS_FUNCTION.
Not quite sure if it's really required, but some tools such as IR-based
decompiler might require this information.
Incorporate PR from Steven Schäfer into IrType-based implicit cast
insertion (commit 17b925636e8717e7648c5d7b792c6ab4d18f776d).
NB this still uses originalKotlinType to determine if the type was
nullability flexible. It is somewhat error-prone and something we want
to get rid of. However, it boils down to some design questions related
to implicit null checks in Kotlin - e.g., it might be Ok to just treat
nullability flexible type `T!` as `T?` in IR, generate null checks for
all usages of type `T?` where a non-null type is expected, and later
eliminate the null checks that are redundant according to the (quite
conservative) criterion in the redundant null check elimination.
Given an expression with SAM conversion, e.g.:
```
fun test(a: Any?) {
if (a is () -> Unit) {
Runnable(a).run()
}
}
```
Here `Runnable(a)` expects `a` to be a value of functional type
`() -> Unit` (and corresponding type check makes smart cast possible).
Relation between `Runnable` and `() -> Unit` is somewhat non-trivial,
is implemented in terms of KotlinTypes and DeclarationDescriptors,
and so should be encapsulated in psi2ir if possible.
Thus, psi2ir generates IR such as
```
TYPE_OP type=java.lang.Runnable origin=SAM_CONVERSION ...
TYPE_OP type=kotlin.Function0<kotlin.Unit> origin=IMPLICIT_CAST ...
[| a |]
```
and InsertImplicitCasts knows that IMPLICIT_CAST actually might be
unnecessary (which also allows to use InsertImplicitCasts in some other
context that might require IMPLICIT_CAST rewriting, such as inlining).
Ideally, the type of `IrWhen` should be provided by type inference for
a consistent behavior. `USED_AS_EXPRESSION` from CFG isn't always
consistent with type inference, unfortunately.
The behavior is now aligned with `if`. The type of `when` is kept when
it *can* be an expression, instead of whether it is used or not.
Delegated properties now have their $delegate fields recorded in the
metadata (in `ClassCodegen.generateField`). This part of metadata is
used by `KPropertyN.getDelegate` functions, so almost all tests on
getDelegate are now unmuted
Cleanup TypeConstructors & KotlinTypes in VariableFixationFinder
Cleanup TypeConstructors & KotlinTypes in TypeVariableDirectionCalculator
Cleanup KotlinTypes in TypeCheckerContext for ConstraintSystem
Cleanup KotlinTypes in NewCommonSuperTypeCalculator
Cleanup KotlinTypes in TypeApproximator
Cleanup type substitution
Cleanup NewTypeVariable
Cleanup StubType
Cleanup TypeCheckerContext creation, extract common supertype context
Provide TypeSystemInferenceExtensionContext via dependency injection
Steven Schäfer