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
Replace iteration over all tasks with `.matching { ... }` with `
.configureEach { if (...) ... }`, so that the check iterates
just over those tasks which are triggered to configure from
somewhere else.
Issue #KT-31666 Fixed
Fore the case where a target has been created or configured twice with different presets,
avoid showing "null" inside the error message if existing target has not preset,
and append a point.
Allow completion of physical files as it is the case for injected Kotlin code.
Also, fix function completion for that case as `document.charsSequence` for injected code document is not dynamically updated as for usual document.
So, we should to do it manually
#KT-31117 fixed
Optimize imports may be called after executing command, and document can be uncommitted after command is finished. In that case we will get ISE: Attempt to modify PSI for non-committed Document
#EA-209693 fixed
Ilya Matveev