it is impossible to declare test data with another output yet
as `myScriptFile.test.ll.kts` won't be treated as custom definition as
it requires `test.kts` extension.
^KT-66232 Fixed
^KT-66276
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
^KT-59297 Fixed
'ProcessCancelledException's are commonly thrown during code analysis,
yet not every place is ready for them. As a FIR tree is a mutable data
structure with no transaction support, sporadic halts during its
mutation might easily leave it in an inconsistent state.
Before this change, whole module sessions (with all dependents) were
invalidated if an exception occurred during their analysis. Not only it
was very ineffective, it also resulted into a concurrency problem.
'ProcessCancelledException's are thrown when an underlying progress
indicator is invalidated. As analysis in each thread might have its own
progress indicator, invalidation in one thread should not stop
analysis in others. However, it is impossible in the current state,
as all threads share the same FIR tree structure.
The change introduces 'FIR guards' – a set of instructions defining
preservation and restoration rules for individual state items. As each
resolution phase is supposed to modify only a (sort of) known subset
of tree elements, restoration of potentially changed state on a failure
effectively returns the tree consistency.
Note that guards are not defined for certain phase transformers. The
reason is that the transformers already update the tree content safely.
E.g., the type reference is updated once it is resolved, and already
resolved type references are either resolved the same way again, or
just skipped on consequent phase runs.
The following two registrars were missing:
- FirScriptingCompilerExtensionIdeRegistrar
- FirScriptingSamWithReceiverExtensionRegistrar
`FirScriptingCompilerExtensionIdeRegistrar` was introduced as a copy of
`FirScriptingCompilerExtensionRegistrar` adapted for usage from IDE.
`FirRegisteredPluginAnnotations` and `FirJvmTypeMapper` are mandatory at
`FirExtensionService.registerExtensions` and reported as missing at
runtime.
- Our current FIR caches are based on `ConcurrentMap` and thereby do not
support size and lifetime limits out of the box. For example,
first-layer caches with a limited size can speed up access of the most
frequently used elements, while having a small memory footprint.
- Caffeine is a modern and well optimized caching library that allows us
to create thread-safe and performant caches with various size or
lifetime limits.
- The cache must support concurrency because session components such as
symbol providers may be accessed concurrently once parallel resolve in
the Analysis API has been implemented (see KT-55750). Caffeine caches
support concurrency.
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
Dmitrii Gridin