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
Note: Kotlin Maven artifacts (./gradlew publish) changed their
dependency on kotlin-reflect
Review: https://jetbrains.team/p/kt/reviews/6753
Why: I'm going to replace source dependency on kotlin-reflect with
binary dependency. Normalize reflect dependency before global
processing.
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
We have [Int|Long|Char]Range classes in 2 different places:
- as separate class-files
- serialized in the kotlin_builtins file
For some reason our Kotlin compiler during the JVM compilation
re-arranging the order of the annotations, so in class file they
will be written in the following order:
- Deprecated
- SinceKotlin
- ExperimentalStdlibApi
But in the kotlin_builtins they will be stored the same way as
in the sources.
We need these 2 way to be synchronized, because stub's in IDE
cares about order.
After this commit IDE test BuiltInDecompilerConsistencyTest is fixed
But still cherry-pick them when serializing builtins because they are
used in builtins signatures.
Merge-request: KT-MR-6488
Merged-by: Ilya Gorbunov <Ilya.Gorbunov@jetbrains.com>
This scheme will be common for all compiler plugins with K1 and K2 support:
- `plugin-common` contains classes shared with K1 and K2 implementations (if any)
- `plugin-k1` contains implementation for K1 compiler
- `plugin-k2` contains implementation for K2 compiler
- `plugin-backend` contains implementation for backend extensions (if any)
- `plugin-cli` is module for registration of plugin in CLI compiler
- `plugin` is a root module with tests and all submodules embedded
This structure is needed to distinguish parts related to different frontends,
which is needed for proper dependencies settings for Kotlin IDE plugins
Anže Sodja