This commit fixes:
Caused by: java.lang.NoClassDefFoundError: com/intellij/openapi/components/ComponentManager
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:555)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:458)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3166)
at java.base/java.lang.Class.getMethodsRecursive(Class.java:3307)
at java.base/java.lang.Class.getMethod0(Class.java:3293)
at java.base/java.lang.Class.getMethod(Class.java:2106)
at org.jetbrains.kotlin.config.JpsUtilsKt$isJps$2.invoke(JpsUtils.kt:17)
In c1f2d66ed8 I replaced
`ApplicationManager.getApplication() == null` with
`Class.forName("ApplicationManager").getMethod("getApplication").invoke(null)`.
It turned out that those two are not equivalent.
`getMethod` tries to match queried signatures with existing signatures
=> it tries to load classes in signatures => it tries to load
`com.intellij.openapi.application.Application` (and fails because
`Application` supertype isn't in the classpath).
Contrary, `ApplicationManager.getApplication() == null` doesn't try to
load `com.intellij.openapi.application.Application` class, so it doesn't
fail.
I use MethodHandles API because it forces me to write `Class.forName`
myself (compared to implicit `Class.forName("Application")` inside
`getMethod`) which I find a nice safety feature.
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>
Add another one reason for rebuild: if pluginClasspaths was changed or even its jar content, module will be marked for rebuild
Merge-request: KT-MR-5839
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
'AbstractCompile' task has inputs that are related only to Java
compilation and should not used for Kotlin compile tasks.
'SourceTask' most probably will be deprecated in future Gradle releases
- https://github.com/gradle/gradle/issues/9040. Plus it has
old 'sources' with 'FileTree' type which is not stable
for task inputs snapshotting.
Another breaking change - 'destinationDir' task property is not longer
available. It is replaced by 'destinationDirectory' which uses Gradle
Provider API type.
^KT-32805 In Progress
newTmpFile can fail, if you pass non-existent path as temp parent directory or java.io.tmpdir is empty or invalid. Now we try to create non-existent dirs and provide more info if it also fails. Also fix error throwing in JPS part(46c0c4f9)
#KT-51374 Fixed
createTempFile can fail, if you pass non-existent path to kotlin.jps.dir.for.module.files or java.io.tmpdir. Now we try to create non-existent dirs and provide more info if it also fails
#KTIJ-17280 Fixed
If LeverVersion is set to greater than 1 of the current compiler version, metadata became null here org.jetbrains.kotlin.load.kotlin.header.ReadKotlinClassHeaderAnnotationVisitor.createHeader, which leads to NPE during incremental analysis. Using the same incompatible data as fallback prevent it
#KTIJ-20954 Fixed
Merge-request: KT-MR-5680
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
NPE was happening on `?.takeIf { it.get(arguments) != it.get(newInstance) }` line.
It was happening because `it.get` could return `null`.
But the problem was only reproducible on TeamCity and not reproducible locally.
Test example (IJ repo): `org.jetbrains.kotlin.idea.fir.completion.HighLevelJvmBasicCompletionTestGenerated$Common$FromSmart.testArrayLiteralAnnotationConstructorAsDefaultValueForArray`
stacktrace:
```
java.lang.NullPointerException
at org.jetbrains.kotlin.arguments.CompilerArgumentsSerializerV5.serializeTo(CompilerArgumentsSerializer.kt:23)
at org.jetbrains.kotlin.config.FacetSerializationKt.writeLatestConfig(facetSerialization.kt:379)
at org.jetbrains.kotlin.config.FacetSerializationKt.serializeFacetSettings(facetSerialization.kt:422)
at org.jetbrains.kotlin.idea.facet.KotlinFacetConfigurationImpl.writeExternal(KotlinFacetConfigurationImpl.kt:24)
```
Create extension of "load classes by parent classloader" logic to bypass clash of the same classes with different versions, loaded by different classloaders in case of running in-process compilation in debug configuration.
#KT-49786 Fixed
GitOrigin-RevId: 173749ef1a36fdb1df44e98f3d373941e00f29ad
Original commit: https://github.com/JetBrains/intellij-community/commit/16e76333d4163c3772fa6e6ef3c1c7667a4c12f9
Since versioning of LookupSymbolKeyDescriptor was added in 1.5.30: f6b428f2 "KT-34862 use abi snapshot instead of build history files", it is necessary to update version of caches for JPS, as new caches are not compatible with previous.
#KT-48399 Fixed
GitOrigin-RevId: 59b1071c1a1090f78c51824d45e6c000f4ef2f3f
Original commit: https://github.com/JetBrains/intellij-community/commit/658f4aeb603bb224a14a92933ebe519948db7745
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
Starting from 1.6.0 the compiler supports three previous API versions, i.e., 1.3, 1.4, 1.5. Note that it's only about API versions, two previous language versions are supported as previously. See KT-49006 for details.
^KTIJ-19978 Fixed
GitOrigin-RevId: e1ba99ac25135959d8b81287850798a222643c88
Original commit: https://github.com/JetBrains/intellij-community/commit/d256c4653ab5aa730e522d282aed49a83f0c99f8
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
Dmitry Gridin