Creating javadocJar task for every project produces lots of unnecessary
tasks, some project don't even have code. Jar task without outDir
property set fails idea import with gradle 5.0+
Rewrite CharArray to String conversions to appending chars one by one.
Refine parameter checking in String(chars, offset, length) to adhere to
the common exception contract and document it.
#KT-29003
CharBuffer had capacity to hold 2 chars, which was not enough to append
a surrogate pair when the buffer was not empty.
The buffer was extended and the decoding algorithm rewritten to deal with
a buffer of any length.
#KT-28572 Fixed
Instead of mutating the matcher create a new one when `next()` is called.
This allows getting named groups from that matcher later.
Add lookbehind in matchSequence test to ensure this change doesn't alter
the existing behavior.
Also fixes #KT-20865
Provide additional modular artifacts as a workaround for KT-21266
Update module-info declarations:
- add new packages
- add exports and opens for internal PlatformImplementations
- remove exports of kotlin.coroutines.experimental.*
#KT-27919 Fixed
This is required to provide the corresponding expect exception in stdlib/common.
Raise deprecation level for constructors declared in common but unsupported in JVM.
#KT-26598
Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
Kevin Peek