- Add BCV to root project to commonize version
- Remove BCV from kotlinx-metadata-klib as it is not necessary for now
- Remove obsolete entry from kotlinx-metadata apiDump
- Add dependency from :kotlinx-metadata-jvm:check to :kotlinx-metadata:check so TC build can verify integrity of API dumps in both projects
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.
Usage of this function is unsafe because it does not have native compiler
support. This means that compiler won't report UNCHECKED_CAST,
CAST_NEVER_SUCCEED or similar diagnostics in case of error cast
(which can happen immediately or after some refactoring of class hierarchy)
Now it could be only be applied inside settings file pluginManagement
block. This will update both settings repositories and all projects in
the repo with cache redirection settings.
This service allows resolve custom user types from plugins, which allows
to support specifying type arguments of generated supertypes basing
on arguments passed to annotations
This will include Internal* and *Experimental annotations for the
Kotlin Gradle Plugin. The separate module is proposed, so that
additional modules can use those annotations without
a dependency to the full kotlin-gradle-plugin-api module
(see -idea modules)
^KT-54029 WIP
Review: https://jetbrains.team/p/kt/reviews/6753
After we migrated to the binary reflect in previous commits we want to
make sure that people won't accidentaly depend on wrong reflect in the
future.
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
yarn.lock can be changed during the build. It means that gradle plugin contain new versions of npm dependencies and yarn.lock should be updated to be actual. From the other side, we have bootstrap checks, and before bootstrap update following bootstrap gradle plugin can contain following changes in Gradle plugin, and in bootstrap checks yarn.lock is not actual.
So when we update NPM versions, we get one of following situations: yarn.lock is actual either in ordinary build or in bootstrap one, and never is actual in both situation
Sebastian Sellmair