Logic that was used to complete receiver expression is no longer needed
after the `invoke receiver completion` change:
7b46c59d57
Before that change, we could have generated a new receiver expression
during resolution in case of `call() -> call.<invoke>()` resolution,
Here - `call` is newly generated qualified access that wasn't completed.
We were detecting such situations by detecting change in the receiver
between original `call()` shape and output `___.invoke()` shape in
the expression.
After that change, we always complete the receiver of invoke during
`callResolver.resolveCallAndSelectCandidate`
So the logic that detects receiver mismatch and invokes receiver
completion after it isn't needed anymore
Move language version settings, compiler configuration and different
flags there, and use this config everywhere in both backends instead of
GenerationState.
This will hopefully make GenerationState less of a "god object" and
remove the need to have it available everywhere, in particular in JVM IR
lowerings code, in the future.
Also, future refactorings will make it easier to inject backend-specific
behavior into common code, so that we would not need to handle support
of new features in the old backend.
The following transformations were commonized:
* generation of the transformed atomic extension signature
* building atomic array fields (arrays are now supported on both backends JVM and K/N)
* transformation of function calls on atomic array elements
* Generation and invocation of atomic extensions (the only difference is generation of synthetic value parameters)
* Changed synthetic parameters passed to the generated atomic extensions
See, KT-60528
Merge-request: KT-MR-11249
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
We have `BackendKinds.IrBackend` for IR emitted by the frontend.
We need a different backend kind for IR deserialized from klibs.
We cannot use `BackendKinds.IrBackend` for that purpose, because we
cannot have two different `IrBackendInput` subclasses with the same
kind.
We need a different `IrBackendInput` subclass for deserialized IR
because the `IrBackendInput` for frontend-emitted IR contains some
properties like `sourceFiles` which don't make sense for
deserialized IR.
Since we now have two backend kinds for IR artifacts, we need to make
certain functions and classes in the test infrastructure generic
over backend kinds.
Note: the JsIrDeserializedFromKlibBackendInput class is not used
anywhere yet. We will use it in the coming commits.
When optimizing imports, it does not make any sense to account for
type qualifiers which are not directly present in the code
ATM such implicit type references are present for every
callable declaration call
^KTIJ-24877 Fixed
After splitting K1 and K2 tests some multimodule tests in K1 configuration were still running with 2.0 language version. The reason was in misconfiguration of complex multimodule projects - they don't apply override of compiler arguments. This fix added such arguments update.
#KT-60589 Fixed
Dmitriy Novozhilov