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>
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
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>
Now the stub-based symbol provider is reused for common source sets,
which use metadata dependencies. Filtering should be done on scope
level, then declaration provider won't yield them in the first place.
KT-58769
Use existing stub-based JVM library symbol provider for .knm and
.kotlin_metadata files. The only real difference is the scope filtering
by file types
KT-58769
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
Nikolay Lunyak