Motivation: I'm going to drop NonPrivateCallableAdded (KT-62655) in the
next commits. But I don't want to change the existing logic when I drop
it. That's why I have to introduce the "Unknown" case
- Don't inherit `AbstractField` from `Importable`, because it really
is not
- Remove the `arguments` and `nullable` properties from `AbstractField`.
Both properties can be derived from the field's `typeRef`.
- Make `AbstractField`'s `typeRef` property of type
`TypeRefWithNullability` instead of just `TypeRef`, because fields
can always be nullable.
This is the cause for the 'missing dependency supertype: Serializable'
issue: symbols from built-ins will have the additional Serializable
supertype provided by FirJvmDeserializationExtension that shouldn't
be used for non-JVM. In regular modules it is correctly not added by
the non-JVM sessions, leading to difference in supertypes and the error.
KTIJ-27449
It was added as a placeholder in f3c58a1df7 and was not used anywhere.
The used error is declared in `JvmBackendErrors` and is reported by the
backend.
ARGUMENTS_OF_ANNOTATIONS will be dropped, so this check should be moved
This commit also drops class annotations resolution from implicit type
phase and provides the correct scope during argument mapping phase.
This code was effectively unreachable before
^KT-62679
In the previous commit, we started to treat delegated function similarly
to substitution/intersection overrides, so now it's incorrect to name
corresponding methods and storages using "fake-override" word
^KT-62671
Delegated callables in FIR are session-dependant (as fake-overrides),
so it's incorrect to use their FIR as a key for declaration storage.
Pair of original function and owner lookup tag should be used instead
^KT-62671 Fixed
`implicitScope` can be `null`
in case when the implicit receiver resides in a user-defined `kotlin.*`
package, but the user have not yet allowed this with compiler argument
directive.
In this case,
we don't want the IDE to crush and show exceptions - the `kotlin`
package would be highlighted by the compiler diagnostics and other
resolve problems, and that would be enough
^KT-62071 Fixed
In IR interpreter we have "preprocessors". Preprocessor is a
transformer that changes IR expressions in a way that we can
interpret them at least partially.
We have two places where interpretation is happening:
1. Right after fir2ir where we evaluate only strictly necessary
expression for `const val` and annotations.
2. In lowering for every backend where we are doing some
constant folding.
Earlier, to avoid double work, we didn't launch preprocessors
in backend if we were using K2. But this approach breaks compilation
for MPP projects where one module is compiled with K1 into klib
and the overall project is compiled with K2. On the backend side,
we are mistakenly assuming that preprocessors were launched, but they
were not.
The solution is to run preprocessors only on the backend side. If we
think about it, interpretation on fir2ir doesn't require any
preprocessing because we are working only with expressions that are
correct and must be fully evaluated.
#KT-62126 Fixed
When files from different IrModules are merged in IrActualizer
their IrModule link was not updated. This led to assuming them
as different modules, and incorrect internal visibility handling.
^KT-62623
Ideally, instead of this method, there should be a link
to IrModuleFragment. Unfortunately, it would require to big refactoring,
as some of IrPackageFragment implementations doesn't have any
IrModuleFragment inside, and are not located inside any
IrModuleFragment.
So for now, we just implement and use everywhere a single way of
getting the module descriptor, which respects a IrModuleFragment
link if it exists, and fallbacks to descriptor-based method
if it doesn't.
^KT-62623
K1 reports `ARGUMENT_TYPE_MISMATCH`
and `TOO_MANY_ARGUMENTS` together, and
one way to do it in K2 is to say that
their kinds of inapplicability difference
is not relevant to the user.
Note that K1 doesn't do such filtering,
so this change "makes K2 closer to K1",
but still different.
^KT-62541 Fixed
fixup! [FIR] Show ARGUMENTS_MAPPING_ERROR diagnostics along with INAPPLICABLE
Ivan Kylchik