Reimport after `./gradlew build` adds jars from gradle's `build/libs` to facet's classpath. That causes problems with JPS build, because it doesn't see changes in out folder, but see unchanged jar, so changes don't apply.
#KT-51873 Fixed
Merge-request: KT-MR-6018
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Test: Existing IncrementalJvmCompilerRunnerTestGenerated.PureKotlin#testCompanionConstantChanged
and similar *.PureKotlin#testCompanionConstantChanged tests
Fix testdata of new compiler tests for JPS, as it is build-log-sensitive:
ClassHierarchyAffected.testWithIntermediateBodiesChanged
PureKotlin.testSerializedSubClassAndChangedInterfaces
WithJava.JavaUsedInKotlin.testRawErrorTypeDuringSerialization
Mute JavaUsedInKotlin.SamConversions tests, as it was fixed in 212 idea
Add missed part of commit 5f4be072 [JPS] Fix JS incremental compilation
Part of commit, located in JPS module, was missed during JPS relocation
Fix test MixedInheritance for non-JPS builds
Depends on commit [CHERRY PICKED FROM IJ] [testdata] Replace test IncrementalJvmJpsTest...
Replace test because JPS recompile inherited classes only in case of existence of direct use (like override or direct call of parent methods).
Tested cases:
*Add new abstract method when derived class does not abstract
*Add and remove method, when such method is present in derived class
*Change return type/access modifier
GitOrigin-RevId: 767e58ba3d3e4069838c717666329b43f1b8e936
Original commit: https://github.com/JetBrains/intellij-community/commit/d738c61aaefe95acd8130066f53f8d8bcadfa977
Fix test IncrementalJvmJpsTestGenerated$PureKotlin.testPackageFileAdded
Fix test IncrementalJvmJpsTestGenerated$Custom.testCommonSourcesCompilerArg
Fix test IncrementalJvmJpsTestGenerated$WithJava$JavaUsedInKotlin$SamConversions.testMethodAddDefault
GitOrigin-RevId: 63b7a47898ca42b4d7f11a01ceb0e019933f528b
Original commit: https://github.com/JetBrains/intellij-community/commit/e91bfb29e65b9eb5452c4d5f544f0bbfa3eafde3
Possibility to use JDK 9 was dropped in the Kotlin repo in
this commit de7fb9606a so I had to migrate this test.
Consulted with @udalov. He said that it's fine to migrate this test to JDK 11
The following tests are outdated (JPS/Js is no longer supported):
- MultiplatformJpsTestWithGeneratedContentGenerated$Simple.testEditingPJsKotlin
- MultiplatformJpsTestWithGeneratedContentGenerated$SimpleNewMpp.testEditingPJsKotlin
GitOrigin-RevId: e4c4b5a75b39803bc5df966a3d957e5ab0f253b1
Original commit: https://github.com/JetBrains/intellij-community/commit/49542e2cce00b08f87c0c91093dff4e8c9df1032
The following tests are outdated (JPS/Native is no longer supported):
- MultiplatformJpsTestWithGeneratedContentGenerated$IgnoreAndWarnAboutNative.testEditingCKotlin
- MultiplatformJpsTestWithGeneratedContentGenerated$Simple.testEditingCKotlin
- MultiplatformJpsTestWithGeneratedContentGenerated$SimpleNewMpp.testEditingCKotlin
GitOrigin-RevId: 6e81a4a86a480563992b6fbde4ecbf47571bb49e
Original commit: https://github.com/JetBrains/intellij-community/commit/2a3a84bfa69853efd0be2eaca183cd615af03080
This commit is consequence of not accurate migration to kotlin-ide repo.
These changes appeared as a result of split of big chunk of first
commits in kotlin-ide repo. I don't know where from changes in this
commit come from.
It could be changes of "bunch switch" commit. Or changes of other
accidentally squashed commits
GitOrigin-RevId: 6d1e18c36e02a4ad228fe7ddc5bd056e98e1be36
Original commit: https://github.com/JetBrains/intellij-community/commit/c490f5864de6ef36964aa4ee34cdf7b3f35db384
Kotlin JPS plugin existed in Kotlin repo before but was migrated to
intellij-community together with entire Kotlin plugin.
Now I return Kotlin JPS plugin back because it turned out that it's
easier to develop JPS in KT release cycle. Also I need to
unbundle Kotlin JPS plugin in scope of KTIJ-11633
Set TargetBackend.JVM_IR for these tests by default; remove the
generated IR-based test and add a new old-backend-based test. This fixes
the issue where some (3) of these tests were not properly ignored
because of incorrect target backend used in the test generator.
Also update test data for some tests which use local functions, which
are not generated to separate anonymous classes in JVM IR.
Original commit: 1deb317e0d
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
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
JPS does not remove output files for files marked as dirty
for current iteration. This is a problem for adding complementary files
during JPS MPP IC.
If output files are not removed, the compiler might raise an error
for duplicated actual declarations.
Original commit: 06275a201c
Previously IC could go to the next iteration without removing
outputs for the files compiled during the last iteration.
For example, it could happen, when a multifile part is changed
(we add sources for other parts and recompile everything together).
In case of MPP it could lead to compile error, because
the compiler would see the same actual declarations from dirty sources
and dirty outputs from previous iteration (which should have been removed).
That behaviour did not raise an error before a5c976d0f751830704daa8b7386fcc288139c35c
because actual declarations from binaries (e.g. compile classpath) were ignored.
#KT-35957 Fixed
Original commit: 4ccec5218f
This fixes the weird cases when a class gets overwritten by an imperfect
copy, reduces the number of classes in the output if an inline function
contains an inline call that causes it to have regenerated anonymous
objects, and makes inlining of same module functions a bit faster in
general. On the other hand, this may increase memory footprint a bit
because classes cannot be flushed to the output jar, as the inliner
would not be able to locate classes for anonymous objects if they have
already been unloaded from memory.
Original commit: 82899e6243
Aleksei.Cherepanov