- Mark @ContractsDsl as @Experimental
- Move Contracts DSL out from 'internal' package
- Change visibility of ContractsDsl from 'internal' to 'public'
^KT-25274 Fixed
^KT-25495 Fixed
K2MetadataCompiler doesn't perform explicit check of compilation of
'kotlin' package, thus stdlib build wasn't passing '-Xallow-kotlin-package'.
However, we have special hack for compiling stdlib with contracts: if
'-Xallow-kotlin-package' is passed, then allow compiling contracts for
custom functions. We have to do it this way, because we don't want
stdlib artifacts to be marked with pre-release flag, even though
contracts for custom functions are not enabled yet
(see eae9923dbe).
Therefore, it's crucial to pass -Xallow-kotlin-package properly for that
side-effect.
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
The problem is happening because our plugin deletes the task from
common projects, which may lead to such errors. The proper fix is
planned in our gradle plugin.
Simplify asserter lookup: enumerate all AsserterContributors when
the file class with lookupAsserter function is initialized.
It's assumed that AsserterContributor initialization should be fast.
#KT-21154 Fixed
build.xml was also changed to incorporate contracts in
mock-runtime-for-tests.jar, because it is using Standard.kt, which, in
turn, has contract-annotated functions.
==========
Introduction of EffectSystem: 17/18
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.
Dmitry Savvinov