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.
This is needed in order to support wrapped properties properly in
KotlinTypeMapper (see the `is PropertyAccessorDescriptor` call in
`mapFunctionName`) which is still being used when mapping function call
signatures
In particular, the JVM backend inlines the bodies of lambdas into the
generated lambda subclasses and stores bound receivers in the receiver
field of CallableReference. Both are required for reflection.
This commit fixes the handling of accessors for super calls, changes the
naming scheme to avoid accessor name clashes and uses a more robust test
to determine the placement of accessors for protected static members.
Previously, the order of IrSetField statements in this lowering was
non-deterministic. This broke the inliner in the JVM backend which
expects statements to be in argument order.
Alexander Udalov