In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 Fixed
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
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
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
To snapshot a Java class (+ its fields and methods), previously we used
Gson to serialize a class field/method to a string via reflection, and
hash that string.
We now use an ASM ClassWriter to write a placeholder class containing
the field/method of interest and hash the bytecode of that class.
One experiment showed that this new approach is ~10 times faster than
the previous approach (140s down to 16s when snapshotting 600 jars).
Test: Updated expectation files for JavaClassSnapshotterTest unit tests
+ Existing integration tests to prevent regression
^KT-52141 In Progress
as we need access to the lookup tracker to compute classpath changes
more efficiently and reduce the size of the saved classpath snapshot.
The previous commit only changed the files' paths, this
commit actually updates the files' contents.
Note that classpath snapshotting still happens in Gradle artifact
transforms. (However, the previous commit also moved the code for
classpath snapshotting together with the code for classpath diffing as
they are closely related.)
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
Some of IDEA services (like in `com.intellij/execution`) was copied,
because they are used in tests but jars with them compiled with
jdk 11 and we run our tests on jdk 8, so their bytecode can not
be read
Previously JS IR versions of stdlib and kotlin-test were build
by default using compiler previously built on a buildserver.
It had some issues:
- This required us to advance bootstrap every time we made any
incompatible IR changes. This happens often since IR ABI is
not quite stable yet.
- We never tested the exact combination of compiler and stdlib we publish
We tested:
- new compiler with new stdlib build by new compiler (in box tests)
- old compiler with new stdlib build by old compiler (in stdlib tests)
We published:
- new compiler with new stdlib build by old compiler
After this change JS IR compiler tests, builds and publishes
single configuration:
new compiler with new stdlib build by new compiler
JS IR stdlib and kotlin-test are now built using JavaExec of CLI instead
of Gradle plugin to avoid troubles of loading a freshly built plugin.
This also allows to have a granular dependencies: we don't rebuild klib
if we changed a lowering in a compiler backend, but we do rebuild it if
we changed IR serialization algorithm.
Each Kotlin task now writes build history to separate file.
A map of output directories to history files is used to get changes for
modified files.
#KT-22623 fixed
When TestLoggerFactory is initialized in tests it checks that variable
and it it's not present uses classpath to search for logger configuration.
If this search is unsuccessful a lot of exceptions are written to log:
java.lang.RuntimeException: Could not find installation home path. Please make sure bin/idea.properties is present in the installation directory.
at com.intellij.openapi.application.PathManager.getHomePath(PathManager.java:96)
at com.intellij.testFramework.TestLoggerFactory.reconfigure(TestLoggerFactory.java:67)
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Nikolay Lunyak