- The symbol provider may additionally provide function types, so we
have to compose its symbol names provider with the synthetic function
type symbol names provider.
- The null symbol names provider knows nothing about the names provided
by its symbol provider, so it also has to assume that the symbol
provider can provide a synthetic function type.
- This inconsistency has not caused an issue so far because
`mayHaveTopLevelClassifier` is also overridden, and
`mayHaveSyntheticFunctionType` is not used outside that context.
- 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
otherwise they are easily swallowed by the reporting logic.
This commit was needed to ensure that the problem described in
KT-63665 is reproducible in IC test
But some JS IC logic relies on handling compiler exceptions as a signal
for scope expansions, and the newly introduced exception logging
broke a few tests. To mitigate it, the directive was introduced
to disable exception logging for particular test.
This fixes failures in performance builds caused by the KT-MR-13291 "Update Gradle to 8.4"
doLast { } block here is necessary as soon as it should be run during the task execution, while without it is a configuration time. Performance builds invoke Gradle several times with different tasks and parameters. The change in the mentioned MR made one of the invocations remove the nativeReports.json file produced earlier.
Merge-request: KT-MR-13496
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Context:
- Kotlin allows functions overloaded with different array element types.
- Varargs are lowered to Array parameters.
- Before this commit, K/Wasm erased an array element type
from the signature, similar to type argument erasure in other cases.
Fix:
Stop erasing type arguments in arrays when computing v-table signatures.
^KT-58852 Fixed
Use a more concrete name, make it private,
and split out:
IrSimpleType.toWasmSignatureSimpleType
This does not change the behavior,
but helps to set the stage for the following bugfix
(KT-58852)
`File.hashCode()` behavior is OS-dependent. This can lead to the loss of mapping between a path and its related data in PersistentHashMap — for instance, when a map generated on Microsoft Windows is used on macOS. Notably, this can occur even though both systems use case-insensitive filesystems by default. This commit returns the hashing based on OS-independent path strings
^KT-64016 Verification Pending
'ContextCollector' is used for computing context of 'FirCodeFragment's.
Code fragments themselves might contain additional smart cast operations
that modify the context receiver stack.
^KT-63056 Fixed
We should unwrap substitution overrides as they sometimes cannot be
resolved on demand. We already have this in KDoc contract.
```kotlin
class MyClass {
val prop = object : LazySchemeProcessor<Int, Int>() {
override fun is<caret>SchemeFile(name: CharSequence) = name != "str"
}
}
abstract class LazySchemeProcessor<SCHEME : Number, MUTABLE_SCHEME : SCHEME> {
open fun isSchemeFile(name: CharSequence) = true
}
```
In this case, we will try to resolve fake override in the context of the
anonymous object, and it will fail because we cannot lazily resolve
local declarations as they are a part of the containing declarations
(KT-64243 for more details)
^KT-64108 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
Mikhail Glukhikh