- Remove obsolete exclusion of core & stdlib modules, since they are now
compiled with JVM target 1.8, but leave `:core:descriptors` because of
an issue in Proguard.
- Remove binary-compatibility-validator and update test data instead.
- Replace some "contains" checks with equality for clarity.
- Remove modules from -Werror filter which no longer use the deprecated
compatibility mode.
This will be a 'lean' jar file (un-shadowed), which can later
be used by the binary-compatibility-validator to test the
API surface against.
^KT-52568 Verification Pending
- Introduce `kotlin-gradle-plugin-idea` module that allows
to share models between the IDE and KGP
- Add `kotlin-gradle-plugin-idea` to the RuntimePublicAPITest to
ensure binary compatibility
^KT-51262
It's no longer required to dump kotlin-to-java declaration mapping to json
before using binary-compatibility-validator.
@JvmOverloads are not supported yet, so remove them from test.
Use asm:6.0 in bcv
Since we're not yet sure of the design of Experimental/UseExperimental,
we're making them "experimental" themselves in some sense, in that the
user is required to provide the magic argument
"-Xuse-experimental=kotlin.Experimental" to be allowed to use either
Experimental or UseExperimental. This is more convenient than the
previous approach of "-language-version 1.3
-Xskip-metadata-version-check" because it's simpler and does not cause
pre-release binaries to be produced
This is needed only for faster compilation of the Kotlin project itself
and has no effect on the public artifact
org.jetbrains.kotlin:kotlin-reflect.
The problem this is solving is the rebuild of the project once anything
has been changed in modules in 'core' (even inside function bodies, i.e.
a non-API change). Previously, changes in 'core' led to the compilation
of kotlin-reflect, which led to the rebuild of all modules depending on
kotlin-reflect directly or indirectly (which is almost all modules in
the project) because kotlin-reflect's artifacts are custom-built and the
changes can not be picked up incrementally. But 99.9% of the time the
initial changes in 'core' could not have any effect on the usages of
kotlin-reflect, because classes from those modules are moved to an
internal package in kotlin-reflect and thus are an internal
implementation detail.
Now, changes in 'core' still lead to the compilation of kotlin-reflect
and to the process of building the custom jar. But if a module depends
on kotlin-reflect-api, not kotlin-reflect, then the incremental
difference checker will detect that the module does not have to be
recompiled if there hasn't been any changes to the API of
kotlin-reflect-api. Which means that the module will not be rebuilt on
every change in 'core'.
This commit only introduces the new module. The dependencies
(kotlin-reflect -> kotlin-reflect-api) are replaced in the next commit.
The idea is to keep all declarations in the same packages from Kotlin's
point of view, but use JvmPackageName annotation to move them to another
JVM package, to avoid the split package problem which is otherwise
unsolvable when using module path on Java 9 (KT-19258).
In this commit, kotlin-stdlib-jre7/8 are moved to kotlin-stdlib-jdk7/8
and in the subsequent commit, -jre7/8 are restored. This is done in
order to make Git recognize this as a file move to preserve history.
Include new stdlib-jdkN artifacts in manifest version tests.
Dmitriy Novozhilov