Currently, there is only attribute `ExpectForActualAttributeKey`
where mapping is stored only for source declarations with `actual`
modifier. But we need mapping of all class members, including classes
which were actualized via `actual typealias` or fake override members.
This data will be needed for the annotation checker in subsequent
commits.
^KT-60668
^KT-60936
Disabling the language feature is supported,
otherwise there are too many tests that
would need to be updated to account for
K2's inability to do it.
The `ifConstVal.kt` test is deleted,
because now it must also be ignored in K2,
and since it is ignored for both the
frontends, and the ignored backends
include all the target backends, this test
is basically unused.
Note that now both the frontends report
`CONST_VAL_WITH_NON_CONST_INITIALIZER`.
for `condition`.
^KT-55196 Fixed
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
- Specify disambiguating attributes in kotlin-dom-api-compat
compile dependency configurations
because it uses the flag that removes JS compiler type attribute
from all configurations and variants
KT-56106
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.
By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
Implementation is very similar to the `enumValues` intrinsic.
Java enums and old (pre-1.9) Kotlin enums will be supported in a
subsequent commit.
#KT-59710
In early prototypes of interpreter, it was easier to assume that
all classes from Java can be interpreted and fix something if not.
Check for Java declaration was done by checking that the package name is
starting with "java". But this is actually wrong and can lead to errors
when some code is declared in "java" something package, but is not from
Java stdlib.
#KT-60467 Fixed
This is important for IR lowerings like PolymorphicSignatureLowering
which are very sensitive about the correct types of expressions and
placement of coercions to Unit (KT-59218).
A boolean parameter to `insertImplicitCasts` is not the best solution to
ensure that coercion to Unit is added. The best solution would be to fix
the TODO and generate coercion to the block's type for the last
statement. But that will affect many other places and will need to be
done separately => KT-59781.
Code in IrInterpreter is uncommented to fix the FIR test
`compiler/testData/ir/interpreter/exceptions/tryFinally.kt`; otherwise
evaluation of the function `returnTryFinally` there crashes with
"NoSuchElementException: ArrayDeque is empty". No idea why this test
didn't fail for K1 though, since the created IR is exactly the same.
For some unknown reason this breaks WASM backend with K2, but not with
K1 => KT-59800.
Roman Efremov