These arguments switch language features which cannot be disabled
anymore because they're enabled from some LV not later than 1.4, and the
minimal supported LV is currently 1.4.
Workspace Model will return a copy of CompilerSettings instead of reference to the original one. Thats why we need to add listeners on it on IJ side
Relates to KTIJ-24647
..to the TargetPlatform during the import process.
#KTIJ-27718 Fixed
Merge-request: KT-MR-13072
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
This is a precondition for obsoleting and finally removing
`-Xexpect-actual-linker` CLI key, which became useless since
the removal of ExpectActualTable.
^KT-61136
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
This commit is needed for adding targetPlatform serialization for Kotlin Facet Settings Workspace Model on IJ side
Merge-request: KT-MR-11953
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
The command line argument parser is using between 0.25s and 0.5s
(depending on platform) on finding annotated properties. This fix
replaces the slow kotlin reflection with java reflection, which is an
order of magnitude faster.
#KT-58183 Fixed
ERROR:
:jps:jps-common:test: Could not find org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.10-release-949.
The problem is in dependency:
com.jetbrains.intellij.platform:jps-model-serialization:213.7172.25 -- (runtime) ->
com.jetbrains.intellij.platform:util:213.7172.25 -- (runtime) ->
org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.10-release-949
Provide a jdk 8 stdlib that should make the resolution of the dependency
redundant.
KTI-1114
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Using of Kotlin reflection for simple operations like bean management is very slow
First time initialization time: 261 ms for `copyBean(K2JVMCompilerArguments())`
Subsequent calls of `copyBean(K2JVMCompilerArguments())` take 1.7 ms per call
Unfortunately compiler argument handling is also used in Kotlin IntelliJ plugin
to parse facet settings. Big projects may have thousands of Kotlin facets
The same `ArgumentUtilsKt.copyProperties` frame is seen across various freezes:
IDEA-252440 2-3 minutes freeze on Kotlin project reimporting in last 203 eap
IDEA-253107 A lot of short freezes (1-3 sec) during Kotlin project development
KTIJ-23501 Make main run configuration detection lighter
KTIJ-22435 Unresponsive UI with 100% cpu
Reflection issue:
KT-56358 KClasses.getMemberProperties takes too much time
This commit replaces all reflection stuff with a simple code generation
Now `K2JVMCompilerArguments().clone()` goes to hard-to-measure time
Facet serialization is located in Kotlin repo, and it uses new(1.9.*) stdlib in compile dependencies. But when it is used by IJ it has previous runtime stdlib dependency (looks like 1.8.0). So here is workaround, that specifies apiVersion and languageVersion, that does not produce such problematic outputs.
#KTIJ-24903 Fixed
Merge-request: KT-MR-9333
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
make write protection directly in properties
it creates no additional wrapper with the link to the containing class
for ij project, this reduces memory usage for ~15 mb
^KT-56351
JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
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>
Ilya Goncharov