It leads to further infer type variable into those upper bounds which is forbidden
Substituted upper bounds is ok because specific substituted types came from constraints of other proper positions, or if specific substituted type is from declared upper bound too, then there should be another declared upper bound with no substitution
^KT-51464 Fixed
^KT-47986 Fixed
Sorting invokes descriptor renderer, so the fewer descriptors we are
sorting, the better. This helps to save a few percent of compilation
time in a synthetic project from KT-52326.
`kotlin-jps-plugin-classpath` isn't dropped because, in some places, IDE
depends on the old artifact so I want to keep it for a while until I
cleanup IDE completely.
I tried to put as much libraries into `kotlinJpsPluginMavenDependencies`
as possible in the previous commit. Right now,
`kotlin-jps-plugin-classpath` is 33Mb, `kotlin-jps-plugin` is 20Mb (all
are not compresed)
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.
It was duplicated in the only usage of `compilerModulesForJps` --
`prepare/ide-plugin-dependencies/kotlin-jps-plugin-classpath/build.gradle.kts`
This commit doesn't change any logic.
This commit places all dependencies of JPS plugin into a single place --
`compilerModulesForJps`. I will need this small refactoring for the next
commits.
This commit doesn't change any logic because
`prepare/ide-plugin-dependencies/kotlin-jps-plugin-classpath/build.gradle.kts`
is the only `compilerModulesForJps` user right now.
- 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.
Reasons:
1. Those modules don't use this dependency
2. Unbundled JPS feature in IDE downloads all transitive dependencies of
kotlin-dist-for-jps-meta => downloads org.jline and puts it into dist
which is not needed
^KTIJ-20875 Fixed
This artifact is used to denote maven artifacts from which IDEA Kotlin
plugin should compose kotlinc dist layout to use it in unbundled JPS
(KTIJ-11633)
Right now kotlin-dist-for-jps-meta tries as close as possible to a real
dist except for:
```
js.engines.jar
kotlin-ant.jar
kotlin-preloader.jar
mutability-annotations-compat.jar
// It's compiler/cli/cli-runner.
// It is `kotlin` in CLI and not needed for JPS
kotlin-runner.jar
// JPS doesn't support KAPT
kotlin-annotation-processing-cli.jar
// Sources
kotlin-annotations-jvm-sources.jar
kotlin-reflect-sources.jar
kotlin-script-runtime-sources.jar
kotlin-stdlib-jdk7-sources.jar
kotlin-stdlib-jdk8-sources.jar
kotlin-stdlib-js-sources.jar
kotlin-stdlib-sources.jar
kotlin-test-js-sources.jar
kotlin-test-junit5-sources.jar
kotlin-test-junit-sources.jar
kotlin-test-sources.jar
kotlin-test-testng-sources.jar
```
^ for elaboration on the list see KTIJ-20875
This commit is going to be cherry-picked to a bunch of old Kotlin
versions, so it needs to be conservative
Alternative fix: I could create a Gradle module but I didn't do that,
because I can't refer to compiler plugin maven modules which are also
specified in Maven poms `libraries/tools/kotlin-maven-*/pom.xml`.
1. `api(project(":kotlin-maven-allopen"))` in imaginary Gradle fix
obviously doesn't work
2. `api("org.jetbrains.kotlin:kotlin-maven-noarg:${project.version}")`
kinda works... but at least breaks IDE import (most probably, it
breaks something else as well)
Victor Petukhov