At the moment, SubclassOptInRequired is marked with the
ExperimentalSubclassOptIn annotation. However, it does not work
as expected due to a missing opt-in error. To use SubclassOptInRequired,
an explicit opt-in is necessary because SubclassOptInRequired is an
unstable feature now.
^KT-64739
It is required for stabilizing previously experimental
builtin functions and classes (KT-53778)
in order to mark them WasExperimental,
so that they are available for previously opted in users
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
Initially, it was added accidentally as part of e3f987459c
and missed all out processes.
Adding @SinceKotlin("1.7") after the annotation has already been
published before is not really a problem, because it only may be used
with an experimental `-Xcontext-receivers` flag, thus it doesn't have
to be a part of our regular backward compatibility routine.
^KT-55226 Fixed
Skip SOURCE-retention annotations in builtins serialization tests,
because otherwise the source analysis result can't be equal to the
metadata deserialization result.
#KT-53073 Fixed
We have [Int|Long|Char]Range classes in 2 different places:
- as separate class-files
- serialized in the kotlin_builtins file
For some reason our Kotlin compiler during the JVM compilation
re-arranging the order of the annotations, so in class file they
will be written in the following order:
- Deprecated
- SinceKotlin
- ExperimentalStdlibApi
But in the kotlin_builtins they will be stored the same way as
in the sources.
We need these 2 way to be synchronized, because stub's in IDE
cares about order.
After this commit IDE test BuiltInDecompilerConsistencyTest is fixed
- Int.toChar was left non-deprecated because the replacement is not intrinsic yet.
- Number.toChar was left non-deprecated because otherwise the deprecation propagates to the override, Int.toChar.
KT-23451
Add Char.MIN_VALUE and Char.MAX_VALUE implementations in primitive companion objects.
Update builtins test data and public API.
Co-authored-by: Oskar Drozda <themppsplx@gmail.com>
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
- White list: can be used as common built-in declaration
- Black list: can be used only for overrides and super-calls-
- Not considered members: ones that is not in black or white list.
Such members can be used in any context, but they usages marked as deprecated
Third kind is needed to make possible use declarations added in future JDK versions.
Deprecation is necessary because they may get into black list in next Kotlin compiler version
Anastasia.Nekrasova