This commit fixes two tests related to removed workaround of KT-59818,
and also makes processing suspend functions in J/K hierarchy more consistent.
Before this commit, when we had Java class "suspend" method
(implemented with the help of Continuation) overriding Kotlin suspend fun,
the Kotlin suspend fun was visible in outer use-site scope,
and the Java method was invisible.
Also, we used a special "Java suspend view" just to determine
that Java method overrides Kotlin suspend fun and no more.
After this commit, Java class "suspend" method will be visible
in this hierarchy and Kotlin suspend fun will not.
Also, the "suspend" is visible as a synthetic Kotlin suspend fun
which is more correct.
Related to KT-63233
#KT-59818 Fixed
FirJavaMethod and FirJavaConstructor are implementation classes.
It's anyway not good to check subtyping using them,
because it makes the code implementation-dependent.
This commit begins to check Java origin instead.
We used this classId to get an associated symbol,
but this way is anyway not recommended (e.g. problems with local classes).
In this commit we migrated to usage of lookup tags instead.
- Previously, only callable package name sets were implemented, because
the compiler cannot economically compute classifier package sets for
libraries. This has not changed. However, the K2 IntelliJ plugin and
standalone Analysis API can very easily compute classifier package
sets. Hence, this commit adds support to `FirSymbolNamesProvider` for
such sets.
- Similar to callable package sets, classifier package sets (1) improve
the memory usage of symbol names providers and (2) improve the
performance of `mayHaveTopLevelClassifier`, which is a significant
bottleneck in the IDE.
- In many cases, the package sets for callables and classifiers are the
same. For example, the IDE Kotlin declaration provider computes the
set of packages that contain any classifier and/or callable, for the
following reasons: (1) indexing package names without filtering for
declarations is much faster, (2) computing separate sets is not free
both in time and memory, and (3) the performance impact of having a
more narrow set for callables is expected to be negligible. For this
reason, `FirSymbolNamesProvider.getPackageNames` exists to provide a
shared package set.
- The `hasSpecific*PackageNamesComputation` properties are required to
avoid caching the same package set in cached symbol names providers
twice. Because these properties are constant, they can be checked very
quickly, and no time has to be wasted trying a specific package set
computation to find out whether it's supported.
### IDE Performance Results
Package set construction performance improved in the IDE in multiple
benchmarks. This improves the performance of symbol providers overall,
which has a direct impact on completion, code analysis, and Find Usages.
In a local manual run of the `intellij_commit/setUp` Find Usages
performance test, the total time spent in `getClassLikeSymbolByClassId`
improved from ~18.7s to ~11.2s. Due to parallel resolve, this does not
translate to a wall clock improvement of 7 seconds, but rather of a few
seconds.
Some performance tests improved markedly in warmup, with for example
`toolbox_enterprise/genUuid` Find Usages having an improvement in
`StubBasedFirDeserializedSymbolProvider.getClassLikeSymbolByClassId`
from 2.4s to 0.2s. This has a direct impact on the first-run performance
of the tested Find Usages command.
So far, classifier package sets in the IDE are only implemented for
libraries, and library sessions are cached after the first warmup.
Because the biggest impact of classifier package sets is avoiding
computation of "class names in package" sets, the impact of this
optimization is not accurately reflected in the timings reported by our
performance tests. `toolbox_enterprise/genUuid` above is a good example,
as the warmup timings are great, but after warmup,
`StubBasedFirDeserializedSymbolProvider.getClassLikeSymbolByClassId`
improved only from 150ms to 70ms.
`toolbox_enterprise/genUuid` is another example, as we can confidently
say that the first-run Find Usages performance has improved (which makes
a difference for the user), but it is unclear by how much, as warmup is
not measured in performance tests.
The same optimization for source sessions will be easier to measure, as
source sessions are invalidated after each performance test run. This
commit lays the groundwork for that as well, because source session
support only requires the requisite package set computation in the
IDE declaration provider to be implemented.
^KT-62553 fixed
When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
This fixes a false positive overload resolution ambiguity in FIR
when invoking a record constructor when it also defines a canonical
constructor (compact or explicit).
#KT-62151 Fixed
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
Before this commit, we first tried to guess a type of array literal
in deserialized annotation (it's a strange heuristics which can
lead to SOE and maybe not needed at all, see KT-62598, KT-62929),
and then, if unsuccessful, took the type from the first literal element,
if any. Since the second heuristic is much more clear, safe, and
understandable, in this commit they were swapped.
This commit does not fix KT-62598 in general case,
but decreases a set of cases when it can occur to
empty array literals only.
See the commented line at the end of the added test.
- This is more consistent with "top-level callable names in package" and
simplifies the set construction quite a bit, as we can avoid a lot of
`asString` conversions.
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
Mikhail Glukhikh