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.
* 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
Split import handlers into multiple files
Add empty Maven handler for Android Studio
Add testRuntime dependency on kx-serialization-plugin for all modules which require compiler
plugins in test classpath
Updated version to 0.5.1
Fix resolving serializers for classes from other modules
(Kotlin/kotlinx.serialization/153)
Respect @SerialName on classes
Add support for @SerialInfo on class-level
Ilya Gorbunov