Use custom project descriptor instead.
Mitingate flaky failures:
ERROR: Save settings failed
java.lang.RuntimeException: java.io.IOException: Cannot save /test_path/test.ipr.
Unable to open the file for writing.
at com.intellij.util.ExceptionUtil.rethrow(ExceptionUtil.java:116)
at com.intellij.util.lang.CompoundRuntimeException.throwIfNotEmpty(CompoundRuntimeException.java:106)
at com.intellij.configurationStore.SaveResult.throwIfErrored(SaveResult.kt:59)
at com.intellij.configurationStore.ComponentStoreImpl.save$suspendImpl(ComponentStoreImpl.kt:152)
at com.intellij.configurationStore.ComponentStoreImpl$save$1.invokeSuspend(ComponentStoreImpl.kt)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)
at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:274)
at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:84)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:59)
at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:38)
at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
at com.intellij.configurationStore.StoreUtil$Companion.saveSettings(storeUtil.kt:44)
at com.intellij.configurationStore.StoreUtil.saveSettings(storeUtil.kt)
at com.intellij.openapi.project.impl.ProjectImpl.save(ProjectImpl.java:157)
at org.jetbrains.kotlin.idea.codeInsight.generate.AbstractGenerateTestSupportMethodActionTest$setUpTestSourceRoot$1.invoke(AbstractGenerateTestSupportMethodActionTest.kt:22)
at org.jetbrains.kotlin.idea.codeInsight.generate.AbstractGenerateTestSupportMethodActionTest$setUpTestSourceRoot$1.invoke(AbstractGenerateTestSupportMethodActionTest.kt:20)
The removed code is probably an outdated code from the age when Kotlin
compiler was using VirtualFiles for operating. Previously the links were
stored and passed further, but now it is only some additional check
(files are unused after the check) with an implicit dependency to
IDEA internals.
The deleted check could probably be responsible for handling references
to JS libraries because of the working compiler daemon.
The code was spotted during an investigation for the
2bf22caeb7 commit (there's a detailed
description in the commit message).
This reverts commit 1f549f32
The revert fixes the flaky behaviour on Windows in jps-plugin tests.
java.lang.RuntimeException: java.nio.file.FileSystemException:
tempdir_path\jps-build\jslib-example.jar:
The process cannot access the file because it is being used by another process.
Can be reproduced when running KotlinJpsBuildTest after IncrementalJsJpsTestGenerated.
1. IncrementalJsJpsTestGenerated sets KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY
2. KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY disables environment clean-up.
3. No disposeApplicationEnvironment() call also means no ZipHandler.clearFileAccessorCache()
4. There's jslib-example.jar opening in JsConfig.checkLibFilesAndReportErrors()
5. File handler is not closed and tests fails in tearDown()
Affected tests:
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
Original commit: 2bf22caeb7
This reverts commit 175dd567
The revert fixes the flaky behaviour on Windows in jps-plugin tests.
java.lang.RuntimeException: java.nio.file.FileSystemException:
tempdir_path\jps-build\jslib-example.jar:
The process cannot access the file because it is being used by another process.
Can be reproduced when running KotlinJpsBuildTest after IncrementalJsJpsTestGenerated.
1. IncrementalJsJpsTestGenerated sets KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY
2. KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY disables environment clean-up.
3. No disposeApplicationEnvironment() call also means no ZipHandler.clearFileAccessorCache()
4. There's jslib-example.jar opening in JsConfig.checkLibFilesAndReportErrors()
5. File handler is not closed and tests fails in tearDown()
Affected tests:
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
In 202 platform tearDown tries to remove temporary directory, but this
fails on Windows, because while Daemon is active directory can't be
deleted.
Original commit: 2ffedd2731
PsiSubstitutor instantiation doesn't need EmptySubstitutor service anymore.
Remove hack with interface field reassign that doesn't work with JDK >= 12.
Leave hack for PsiSubstitutor in AS40 as KotlinCoreApplicationEnvironment
is not expected to be triggered from the plugin.
#KT-36039 Fixed
MissingDependencyClassChecker.collectDiagnostics now show only unique diagnostics
As per-file analyzer trace used in checker delegates to resolve session trace, diagnostics might be duplicated because of race condition:
1. If a non-checker thread performs analyze first, diagnostics for global elements will be stored in the resolve session trace only once.
2 If the checker threads comes to the analyze first, diagnostics will be stored in the local trace, and after that might be duplicated in the resolve session trace by other analyzers.
#KT-35578 Fixed
Nikolay Krasko