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.
Earlier we used a result of a corresponding getter resolution to
obtain a fake overridden field. This approach is incorrect because
the getter resolved may not contain a backing field. This patch
fixes the issue by using the overriddenSymbols property of an
IrField directly.
Issue #KT-33034 fixed
The old compiler will crash if it tries to inline a function that's
passing a lambda parameter into the new parameter null check method
`Intrinsics.checkNotNullParameter` because that usage is not considered as
inlinable by the old compiler (it only knows about
`Intrinsics.checkParameterIsNotNull`). Therefore we require that these
functions can only be read by compilers of version 1.3.50 or greater.
#KT-22275 Fixed
Similarly to previous commit, this method was unused since its
introduction before 1.0, so we're changing its semantics to throw NPE
and starting to use it with API version >= 1.4.
#KT-22275 In Progress
Kotlin compiler strips all debug information for @InlineOnly functions, making them non-debuggable.
This commit disables breakpoints inside @InlineOnly functions to prevent false expectations.
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.
In the old JVM backend, JvmSerializationBindings are created per
ClassBuilder, and special care must be taken to make sure that
JVM-specific metadata ends up in the correct bindings. This is
especially relevant for declarations whose metadata is moved to other
classes away from the place where the original declaration lies, for
example properties moved from companion object to the outer class, or
synthetic methods for annotation properties in interfaces moved to
DefaultImpls, or const properties in multifile parts moved to the
facade.
In the JVM IR backend, this seems not necessary and actually it's
complicated to ensure that we use the correct ClassBuilder for bindings
(see the code simplification in ClassCodegen). Therefore, in case we
don't have an easy way to retrieve the correct ClassBuilder instance, we
now write all JVM-specific metadata to the new _global_ bindings map in
GenerationState, which is used by JvmSerializerExtension as a fallback
if the ClassBuilder's local map has no relevant key.
Alexey Tsvetkov