We'd like to fix the implementation of these methods, so we could intrinsify them later
or perform other optimizations that are not possible when these methods are open.
These methods are very thin wrappers around primitive wrapper classes
constructors.
They are used by coroutines code which returns primitives and this way
HotSpot is able to throw the allocations away completely.
#KT-26591 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.
* The members of Result are isSuccess, isFailure, exceptionOrNull, getOrNull
* The rest of API is implemented via inline-only extensions
* There are two internal functions to hide detailed mechanics of an internal
Result.Failure class: createFailure and throwOnFailure
* Result.toString is explicit: either Success(v) or Failure(x)
See KT-26538
- Move experimental coroutines out of the main source root.
- Include experimental coroutines into the coroutines source set.
- Include release coroutines into the main source set.
This change is valid, since we want StackTraceElement to be as close
as possible to StackTraceElement of non-coroutine code.
Particularly, if the line is inside inlined function, its className,
functionName and sourceFile are inline site's ones, but lineNumber
is large, which is the way of representing inline function's line
numbers. The rest is handled by the plugin, which allows the user to choose
between inline function body and inline site.
Ilya Gorbunov