Introdude deprecation as per KT-21515. Warning is reported on type
usage, that soon will became invisible. Quickfix by adding explicit
import is added.
Idea behind implementation is to mark scopes that are deprecated (see
ClassResolutionScopesSupport).
Then, during walk along hierarchy of scopes, look at deprecation status
of the scope that has provided this classifier.
Note that we also have to check if there are *some* non-deprecated
visibility paths (because we can see classifier by two paths, e.g. if
we've added explicit import) -- then this type reference shouldn't be
treated as deprecated.
Note that there are more places where assertions for inline classes should refined:
- lateinit vars
- values that come from Java
- type casts (interfaces to inline class type)
Now ExpectActualDeclarationChecker in IDE context
uses common module descriptors for relevant checks.
Compiler still uses own module instead (see comment in checker)
So #KT-21771 Fixed
In an open expected class inheriting an expected interface, abstract
members are now inherited as _open_ fake overrides, not final. Final was
technically safer but also stricter and thus could be unexpected by the
user. In a final class, abstract members are still inherited as _final_
fake overrides. So, the general rule is now the following: the modality
of an expected fake override, which overrides only abstract members, in
a non-abstract class is equal to the modality of that class
#KT-22031 Fixed
Probably, when NI is there this fix will become unnecessary because
there will be no approximation applied, thus the value parameter
will remain Hello<#Captured> instead of Nothing
#KT-17171 Fixed
Fake overrides for abstract members from expected classes should become
non-abstract (final, in fact) in non-abstract expected subclasses
#KT-22031 Fixed
When we an equality or comparison operator expression
with both arguments "statically known to be of primitive numeric types"
(that is, either inferred type T for an operand is a primitive numeric
type, or a smart cast to a primitive numeric type T is possible in the
corresponding context), comparisons should be performed on primitive
numbers with corresponding widening conversions.
This differs from default 'equals' and 'compareTo' implementations in
case of floating-point numbers: for Float and Double, IEEE 754
comparisons are used instead of total order implemented by j.l.Float and
j.l.Double.
Examples:
fun ex1(x: Double, y: Double) = x < y
-- will use IEEE 754 comparison for Double, because
both 'x' and 'y' have type Double
fun ex2(x: Double, y: Any) = y is Double && x < y
-- will use IEEE 754 comparison for Double, because
smart cast to Double is possible for 'y'
fun ex3(x: Comparable<Double>, y: Double) = x is Double && x < y
-- will use IEEE 754 comparison for Double, because
smart cast to Double is possible for 'x',
even though corresponding operator convention is resolved to
'Comparable<Double>#compareTo(Double)' (which would use total order)
fun ex4(x: Any, y: Any) = x is Double && y is Int && x < y
-- will use IEEE 754 comparison for Double with 'y' promoted to Double,
because smart cast to Double is possible for 'x',
and smart cast to Int is possible for 'y',
and least common primitive numeric type for Double and Int is 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
The point is that it's placed in module 'resolution' where it can be
accessed for example in ArgumentsToParametersMapper to load default
argument values from expected function
'hasDefaultValue' needs to be adapted to support locating default values
in 'expect' functions, and this is not possible in module 'descriptors',
where it was originally declared. Therefore, move it to module
'resolution' and copy its current logic to a separate function
'declaresOrInheritsDefaultValue' which is used in 5 places.
'hasDefaultValue' itself is updated in subsequent commits.
Besides changing imports, also use a simpler declaresDefaultValue in
some places, which does not include default values inherited from
supertypes: this is OK for constructors, and in LazyJavaClassMemberScope
for functions from built-ins which do not have default argument values
at all
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).
Object model for deserialized protobuf isn't very cheap, so
loading just our stdlib's packages several times (as we do in the IDE)
might lead to ~ 96 MB of retained memory just by these objects.
While in fact many of them remain unused
#KT-21517 Fixed
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
Using the argument value, which is of type "Any?", is more implicit and
thus difficult to read than using the ConstantValue instance and casting
it to the needed constant value implementation before taking the value
Yan Zhulanow