Review: https://jetbrains.team/p/kt/reviews/6753
Meaningful semantic change was splitted into 5 commits to simplify the
change review. Sinle commit would be too big.
Why replace source to binary: to get rid of kotlin-reflect in Kotlin
plugin artifact KTIJ-22276
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
KMA-455
This class was used in intellij but usages was dropped in
a55a62106e40f8545d654d5519576fa4e732d0fd (intellij repo).
DefaultIdeTargetPlatformKindProvider is useless because
`DefaultIdeTargetPlatformKindProvider.defaultPlatform` implementation
always returns `JvmPlatforms.defaultJvmPlatform`
Before this commit `jps/jps-*/build.gradle.kts` list of dependencies
were partially duplicated in the `compilerModulesForJps`
Right now, list of all JPS dependencies is the source of truth.
Actually, I wish I could it do it the other way around -- let the Gradle
do dependency management and correctly produce jars with as less as
possible other libraries being embedded, and as much as poosible
libraries being just dependencies in the pom.xml.
I tried to do so using `embedded` and self-made configurations but
desperately failed, because was getting to big
`kotlin-jps-plugin-classpath` jar. Probably, what I was getting is a
correct classpath, and currently hardcoded classpath may not be
correctly full. Well, at least current classpath is time-proven.
- Some unnecessary dependencies are dropped
- `api` is replaced with `implementation` when it's more appropriate (in
our case more appropriate everywhere). `implementation` makes it
easier to analyze dependencies because it doesn't export the
dependencies
- Regarding: `// Workaround for Gradle dependency resolution error`.
Actually, it's not longer needed for the successful project import.
Confirmed by Yahor and tested locally.
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>
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)
```
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
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
Aleksei.Cherepanov