This commits adds a new annotation OptionalExpectation to the standard
library, which is experimental. To enable its usage, either pass
'-Xuse-experimental=kotlin.ExperimentalMultiplatform' as a compiler
argument, or '-Xuse-experimental=kotlin.Experimental' and also annotate
each usage with `@UseExperimental(ExperimentalMultiplatform::class)`
#KT-18882 Fixed
It's no longer needed for checking binary compatibility.
Clean build of these libraries is no longer required too.
Cleanup build.gradle of binary-compatibility-validator.
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
See https://github.com/Kotlin/KEEP/issues/95#issuecomment-383889404
Drop Experimental.changesMayBreak, Experimental.Impact, the concept of
signature/body usage, same module exemption. Make the majority of tests
single-module because there is now no difference in the checker between
usages from the same module or from another module
Using the new multi-release jar feature, store compiled
module-info.class files into META-INF/versions/9 instead of the artifact
root. Hopefully, this will break fewer tools which do not support
module-info.class files because any sane tool should not do anything
with files in META-INF because before Java 9 that directory only
contained resources.
Upgrade some Maven plugins to newer versions which do not fail on
module-info.class files
#KT-21266 In Progress
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.
Required as a workaround for Proguard bug
https://sourceforge.net/p/proguard/bugs/664/
When processing bytecode generated by Kotlin compiler for constructor
call with stack spilling during arguments evaluation, ProGuard performs
an equivalent transformation for the bytecode, but emits invalid stack
frame information.
In JVM 1.6, such invalid stack frames are ignored and re-evaluated by
JVM during bytecode verification.
In JVM 1.8, such invalid stack frames cause VerifyError.
This is needed to avoid the split package problem on Java 9 (KT-19258):
both kotlin-stdlib.jar and kotlin-reflect.jar export the package
kotlin.reflect
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.
Ilya Gorbunov