Since neither inline function nor super classes affect klib there is no
need for extra passes so compiler doesn't report any dirty files.
Do not check that.
Original commit: daf1da1c70
Supported case then children of sealed classes could be declared
anywhere in a module. If list of classes implementing sealing class
changes the sealed class and all its inheritors should be recompiled
(now sealed class should be compiled together with children in order
to calculate all possible inheritors at compile time) and and
invalidated (as they could have when operators).
Original commit: 36f99156fd
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
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
Test failure was caused by "replace custom source root types to a special
'unknown' type and back on plugin unload/load (IDEA-235292)" in intellij.
We override `getModuleSourceRootPropertiesSerializers` in `KotlinModelSerializerService`
by inheriting from `KotlinCommonJpsModelSerializerExtension`
Original commit: 6985c5fd2a
Otherwise they are detected as common source-sets, thus getting
K2MetadataCompilerArguments (instead of FakeK2NativeCompilerArguments),
and the 'applyCompilerArgumentsToFacets' will fail due to check on
javaClass equality
^KT-39657 Fixed
Original commit: 5b48845dfa
The CompilerMessageLocation is an implicit part of the binary daemon
protocol so changing it breaks compatibility with older daemons.
This change allows to extend location for non-daemon uses without
breaking the binary protocol.
Original commit: 5e33612238
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
Original commit: 012ffa2993
Roman Artemev