- Add marker for the experimental type inference features
- Add annotation that will control builder-like inference
- Require that annotation on corresponding parameters and extensions
- Allow to use builder inference without suspendability
Changes in tests and refactorings (rename mainly) are going to be
introduced in further commits
This introduces new functions instead of the existing sequence builders:
- `sequence` instead of `buildSequence`
- `iterator` instead of `buildIterator`
- `SequenceScope` instead of `SequenceBuilder`
The old functions were deprecated with error and made inline-only, and `SequenceBuilder` has been
made a deprecated typealias to `SequenceScope`.
Move sequence builders to `SequencesKt` facade class.
Replace sequence builder usages in stdlib and samples.
#KT-26678
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.
Ilya Gorbunov