- A `classId` can only be a generated function class if it ends with a
digit, per the contract described in `FunctionTypeKind`.
- The optimization uses this fact to avoid calling
`functionTypeService.getKindByClassNamePrefix`, which can be expensive
due to a hash map access.
- The optimization reduces time spent in `LLFirProvider.SymbolProvider`
during my tests by 30-90% in some highlighted files. In other
performance tests, the optimization makes performance worse, so more
work is needed. In general, higher workload tests run faster with the
optimization, while lower workload tests run slower. This is expected
as the optimization trades short-term performance (for building
classifier/callable name sets) in favor of long-term speedup.
- The changes should also reduce the size of declaration caches like
`LLFirProviderHelper.classifierByClassId`.
- Building the name sets has a second use, as a similar optimization can
be implemented for dependent module providers, which may rely on the
sets computed here.
Note that there's no code that checks that
FirReceiverParameter's annotation's use-site target
is indeed `@receiver:`, because otherwise the
annotation wouldn't have made it into
the FirReceiverParameter.
In contrast, in K1 all such annotations are treated
as annotations on a KtTypeReference.
^KT-56769 Fixed
'JvmClassFileBasedSymbolProvider' works incorrectly for some cases,
such as built-in classes. Moreover, the whole declaration binding logic
looks over-complicated and redundant, as we get a 'ClassId'/'CallableId'
from a 'KtDeclaration', and look for it again in indices.
This commit fixes a bunch of failing completion tests:
- HighLevelJvmBasicCompletionTestGenerated
- HighLevelMultiFileJvmBasicCompletionTestGenerated
- FirKeywordCompletionHandlerTestGenerated
After 1cfd2ae7ff, all non-local
declarations became targets for on-air resolution. However, some of
them, including secondary constructors, are not supposed to be used
in that way. The commit restores the previous behavior.
This commits fixes failing tests in the following groups:
- FirIdeDependentAnalysisSourceModuleIsUsedAsExpressionTestGenerated
- FirIdeDependentAnalysisSourceModuleReferenceResolveTestGenerated
- FirOnAirResolveTestGenerated
Library modules depend on all other project modules. Such a
simplification is useful for cross-library analysis. However, this
seems to be rather harmful for PSI->FIR binding as there might be
several versions of the same library in a project.
The implementation is rather limited. Advanced cases, such as
replacing a script with another one with different import directives,
won't work because of non-trivial relationship between 'FirFile' and
'FirScript'.
Normally, 'DefaultErrorMessages' extensions should only be loaded
from the main compiler JAR. However, in the in-process JPS build,
there are two versions of the compiler classes in the process, and
'ClassLoader's there are not fully isolated.
'ServiceManager' loads extensions from both 'META-INF' locations. If
the JPS plugin bundles newer compiler components, newly appeared
'DefaultErrorMessages' extensions will be loaded from the JPS (parent)
'ClassLoader', causing an exception.
Such a problem appeared with 'DefaultErrorMessagesWasm':
- - - - -
java.util.ServiceConfigurationError:
org.jetbrains.kotlin.diagnostics.rendering.DefaultErrorMessages$Extension: org.jetbrains.kotlin.wasm.resolve.diagnostics.DefaultErrorMessagesWasm not a subtype
- - - - -
In the lowered IR there are often references to type parameters whose
containers are not in the current scope. This is incorrect semantically,
but it works in practice due to erasure, so when the mangler is used on
the lowered IR, we don't want to crash the compiler.
Otherwise, the type parameters of the `kotlin.script.state` property
of type `AggregatedReplStageState` were undefined, which led to
building an ill-formed signature for the script class constructor.
Alexander.Likhachev