- Make addFirst/Last and removeFirst/removeLast as members
- Leave getFirst/getLast unprocessed, thus visible for K1, but marked
as deprecated
Though the implementations of getFirst/getLast and synthetic property
access to them are expected to be deprecated as well, it's expected
to be fixed in later commits.
^KT-60659 In Progress
^KT-60769 In Progress
For annotations defined in Java, IrProperties do not contain initializers in backing fields,
as annotation properties are represented as Java methods.
Therefore, it is not possible to use initializer values as default values for constructor parameters.
However, K2 stores default values in annotation's constructor parameters,
so it is possible to fix this issue if they're properly transfered to the IR
and inspected in JvmAnnotationImplementationTransformer
#KT-47702 Fixed
#KT-47702 tag fixed-in-k2
Unfortunately, there are still problems with running JVM backend tests
with JVM target 21 because:
1) The D8 version that we use does not support bytecode version 21, and
updating to a newer version requires to change JVM target of compiler
tests to 11. This will be addressed separately when we enable JVM 21
in tests-different-jdk.
2) Some tests are failing because of KT-60659 and KT-60770:
- builtinStubMethods/bridgesForStubs/emptyStringListAdd.kt
- jdk/stream.kt
- regressions/kt528.kt
#KT-60662 Fixed
Previously, it was reported for List.toArray because, when traversing
supertypes, we've been stopped at j.u.SequencedCollection
as it has no JavaAnalogue.
^KT-60770 Fixed
Bytecode inliner boxes primitive types in class literals of reified type
arguments. This is by design, and we should backport this behaviour to
IR inliner.
^KT-60144: Fixed
In positions outside of calls (e.g. property initializers)
we resolve callable references using a synthetic outer call with the
expected type as parameter type.
If this fails, we previously returned an unresolved reference.
After this commit, we additionally try to resolve the callable reference
with expected type Any.
This lets us report more precise diagnostics like type mismatches or
when multiple overloads exist NONE_APPLICABLE.
#KT-55373 Fixed
#KT-55955 Fixed
Typealias constructor calls are now always wrapped with synthetic
FirConstructorCalls so that the referenced typeAlias can be extracted.
Previously, it was only necessary to map type arguments.
#KT-57780 Fixed
Otherwise, navigation to unresolved reference is impossible ^ KTIJ-26441
In order to avoid duplicated diagnostic, wrapper is still used.
Symbol collector is updated to retrieve symbols from that wrapper.
Merge-request: KT-MR-11381
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
Previous attempt was at 6807ed6642, but it was reverted in 7771e5914d
(see that commit for the explanation). Now it should be fine to remove
these version requirements.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, namely it fixes the ValueClass.kt kotlinp test.
Language feature InlineClasses is enabled since 1.3. The current lowest
supported language version is 1.4, so any compiler that can read
binaries produced by the current compiler also supports inline classes,
which means that the version requirement is not needed anymore.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, because K2 never supported writing this version requirement properly
due to the TODO in `hasInlineClassTypesInSignature`.
Do not try to find PSI element, but always use the IR element offsets
instead. This greatly simplifies test data because we don't need to have
custom PSI- and LT- based diagnostic ranges in every test, and K1/K2
behavior also is mostly the same.
The exact offset ranges are not as important for backend diagnostics, so
it's better to have K2+PSI and K2+LT behaving the same.
Specifically, the case when not all parts of a multifile class are
annotated with `@JvmSynthetic`. Report the error on the
`@JvmMultifileClass` annotation instead of the package directive,
because the latter is difficult to find via IR. This fixes the test
FirLightTreeDiagnosticsTestWithJvmIrBackendGenerated.MultifileClasses.testJvmSynthetic.
#KT-59586
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
Entering a `finally` block can happen from many different places:
through an exception, a jump, or normal exit from the `try` block. When
in the `finally` block, all DFA flows must be merged to have correct
smart casting. However, after the `finally` block, if exiting normally
or because of a jump, the combined flow from within the `finally` block
should not be used, but rather an alternate flow which combines the
correct flows from before the `finally` block.
```
try {
str as String // Potential cast exception
} finally {
str.length // Shouldn`t be resolved
}
str.length // Should be resolved
```
When building DFA flows, track the start of possible alternate flows,
and continue building them until they end. Both of these situations are
now marked on CFGNodes via interfaces.
When building the default DFA flow, and the source node is the end node
of alternate flows, attempt to use the alternate flow with the same edge
label instead of the default flow of the source node.
#KT-56888 Fixed
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
Denis.Zharkov