If an expression 'x' has a definitely non-null type 'T1',
and is used in position with an expected type 'T2',
cast 'x' to 'T2!!' (most common non-null type T*: T* <: T2).
This introduces the following IR built-in functions required for proper
implementation of the number comparisons:
- ieee754Equals(T, T): Boolean,
for each T in {Float?, Double?}
- less(T, T): Boolean
lessOrEqual(T, T): Boolean
greater(T, T): Boolean
greaterOrEqual(T, T): Boolean
for each T in {Int, Long, Float, Double}
When a parameter has a default argument value both in the expected
annotation and in the actual annotation, they must be equal. This check
has been only implemented for the case when actual annotation is Kotlin
source code, and NOT a Java class coming from an actual typealias. The
latter case would require a bit more work in passing a platform-specific
annotation-value-reading component to ExpectedActualDeclarationChecker,
and is therefore postponed.
For now, Java annotations that are visible through actual type aliases
cannot have default argument values for parameters which already have
default values in the expected annotation declaration
#KT-22703 Fixed
#KT-22704 Open
Also make TypeParameterUpperBounds a "strong" incompatibility, meaning
that non-actual members from platform module are _not_ going to be
matched to the expected members if this incompatibility exists between
them, and therefore NO_ACTUAL_FOR_EXPECT will be reported on the
expected declaration, instead of ACTUAL_MISSING on the platform member.
This is needed because the difference in type parameter upper bounds can
have effect on the function signature on the platform (e.g. on JVM,
Array<T> -> T[], but Array<T> -> Comparable[] if T : Comparable<T>), and
it would be incorrect to report ACTUAL_MISSING on the member that has
nothing to do with the expected declaration that happens to coincide
with it in everything except type parameter bounds
#KT-21864 Fixed
In case the referred type is actually an enum that is not found in
dependencies due to a configuration problem, this usage could be valid.
So we can avoid reporting an error here, to reduce the number of
diagnostics.
Also do not report "default value of annotation parameter must be a
compile-time constant" in the same case for the same reason
Fix TypeUtils.makeNullableAsSpecified for SimpleTypeWithEnhancement and
FlexibleTypeWithEnhancement: change nullability of enhancement too. This
fixes several false-positive warnings, like in KT-20855 and KT-20466.
Note that it removes warning in some cases (see testdata change for
uselessElvisRightIsNull.kt). However, this removes warning about
*unnecessary* elvis, i.e. this fixed introduces weak false-negatives, which
is acceptable for the moment.
#KT-20855 Fixed Target versions 1.2.30
#KT-20466 Fixed Target versions 1.2.30
#KT-21238 Fixed Target versions 1.2.30
- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
Denis Zharkov