In the vast majority of tests, diagnostics are reported at a slightly
different location in LT vs PSI. This is because in the light tree mode,
backend errors are reported basically on the start of the IR element,
which is for example the keyword "class" for a class and not its name as
in K1 or in K2+PSI. Similarly, the end of the diagnostic is at the
ending offset of the IR element.
Normally it would be a bit user-unfriendly to highlight the whole class
as red, starting from the keyword "class" and ending with the closing
brace "}". But remember that these are backend diagnostics in the K2+LT
mode, which is only possible in the compiler scenario, not in the IDE.
And in this case, the ending offset doesn't matter at all because it's
not presented to the user, and minor change in the starting offset is
not a problem as well.
There are some tests which legitimately fail in the LT mode because the
corresponding diagnostics haven't been supported. They will be dealt
with in subsequent commits:
testPropertyInlineCycle
testInlineCycle
MultifileClasses.testJvmSynthetic
testSuspendInlineCycle
testIndirectInlineCycle
#KT-59586
In the IDE, there might come declarations from other files/modules
that we link against, but not compile. Type parameters are one of such
declaration kinds.
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.
Jump edge targets are maintained globally within the CFG builder and are
added indiscriminately to `finally` exit nodes. This means that a
`finally` exit node could have a jump edge added which doesn't match how
the `finally` block was entered. Make sure edges are only added to the
exit node if they also exist on the enter node.
#KT-60723 Fixed
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
UNNECESSARY_SAFE_CALL is a warning,
UNEXPECTED_SAFE_CALL is an error, thus
it's a breaking change.
Also see KT-60695.
^KT-59860 Fixed
Merge-request: KT-MR-11210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
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
Many errors are reported in stdlib with these annotations
(SinceKotlin, Deprecated, so on).
But having them only on expect is a valid case. E.g. SinceKotlin added
if some old platform-specific API becomes commonized.
^KT-58551
This implementation only checks annotations set on expect/actual
declarations and requires further refinement (e.g. checking of other
annotation targets, class scopes within typealiases).
^KT-58551
Previously, we applied type arguments as is when converting type alias
constructor calls to IR.
Now, we map them using the expansion of the type alias.
#KT-59743 Fixed
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
Alexander Udalov