This is a temporary solution to fix the problem with sessions that
turned to be invalid at the time of analysis.
Currently, 'FirSession's and associated 'FirFile's are reused
between threads. When an exception, which might be an ordinary one
or 'ProcessCancelledException', occurs during an analysis of a module
file, a 'FirSession' for that module becomes invalid.
As there is currently a single resolution lock in the K2 IDE, other
threads might be waiting for resolution on the same session.
These threads are unaware that the session cannot be safely used
anymore, as it was correct before the lock.
The previous approach with cancelling analysis in all waiting threads
with manual 'ProcessCancelledException' throwing right inside the lock
showed it's incorrect. While some actions might be prepared to sudden
PCEs and can restart themselves, such behavior is not granted
by the platform.
The fix patches a few common places so the diagnostic list and
a file structure tree can be built safely. It is expected that in
some places exceptions caused by an inconsistent FIR tree can revive.
The right, ultimate fix to the problem involves modifying transformers,
so the FIR tree will mutate only when the analysis is complete. Although
it's planned work, it is expected to take quite a time.
ERROR:
:jps:jps-common:test: Could not find org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.10-release-949.
The problem is in dependency:
com.jetbrains.intellij.platform:jps-model-serialization:213.7172.25 -- (runtime) ->
com.jetbrains.intellij.platform:util:213.7172.25 -- (runtime) ->
org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.10-release-949
Provide a jdk 8 stdlib that should make the resolution of the dependency
redundant.
KTI-1114
This should simplify setup and remove task circular dependencies.
Generally users should not be affected by it unless they are configuring
KotlinCompile task explicetly and expect the same configuration will be
present on KaptGenerateStubsTask.
^KT-54468 In Progress
This fixes KotlinCompile task instantiation on configuring Kapt tasks
as well Kapt tasks itself eager realization.
Additionally this change removes circular dependency between kapt and
compilation tasks.
^KT-54468 In Progress
- Replace CompletableDeferred with a simple 'Completable'
- Replace withContext usage for 'withRestrictedStages' with custom
implementation
^KT-58162 Verification Pending
Add logic that rebuilds all sources after the last incremental round of each Gradle IC test and compares caches. The same was already implemented for JPS, but not for Gradle. After all rounds of incremental compilation are completed, another clean build from scratch is produced. All caches after the rebuild are compared with the caches of the last round of incremental compilation. This check is necessary because incremental compilation artifacts should depend on the state of the project, source files, and configuration, and not the chain of changes and incremental builds that led to this state. After the launch, there were several tests that did not satisfy the above conditions, and were muted (KT-56681, KT-55195, KT-56242, KT-56698)
#KT-54991 In Progress
1) Move root util functions to separate CompileRunnerUtils file from IncrementalJvmCompileRunner to leave the only class instance there and to separate util functions
2) Move TestLookupTracker from the abstract parent class location to a separate file as an implementation class
3) Small change naming of building functions just to clarify what they do
4) Some small code-style refactorings
This fixes a false positive resolution error for callable references
to functions with a type parameter that's annotated with
@OnlyInputTypes.
#KT-57994 Fixed
Value parameters annotations are now handled consistently in
factory functions creating this IrValueParameter instances.
In before, it was handled in several different places, which leads to
being sometimes lost, e.g. in LazyFirSimpleFunction.
This caused original problem in interop checks.
^KT-58099
This is a partial revert of 949a39b80f. In the end it turned out not
necessary to prohibit this case (and perform a breaking change), because
JVM backend was fixed to generate it correctly in d73d3c46e2.
#KT-55307 Declined
#KT-55846 Declined
ConeAttributes can have some non-stable info, so we shouldn't render it
Also reduce resolve from IMPLICIT_TYPES_BODY_RESOLVE to TYPES where it is possible
^KT-58141 Fixed
Dmitriy Dolovov