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
Also, fix empty configurations created for targets that have no runtime
outputs (metadata ones, especially), which could get chosen by Gradle
during dependency variant-aware resolution of a `project(...)`
dependency.
See also: d13ca38
With the attribute set, an input configuration that does not require the
Gradle's USAGE attribute but requires Kotlin platform metadata, will
fail to resolve because the attributes set on the consumable
output configurations are not subsets of each other, as follows:
> Cannot choose between the following variants of project :lib:
- metadataApiElements
- metadataDefault
- metadataRuntimeElements
All of them match the consumer attributes:
- Variant 'metadataApiElements':
- Found org.gradle.usage 'java-api' but wasn't required.
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
- Variant 'metadataDefault':
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
- Variant 'metadataRuntimeElements':
- Found org.gradle.usage 'java-runtime-jars' but wasn't required.
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
Issue #KT-26383 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.
Ilya Gorbunov