instead to vie projectDist. With the current project bootstrap scheme a
dependency to the simply built script-runtime project via dist is not
needed anymore, but it breaks proper sources navigation in IDEA.
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.
Probably, it would be more correct to skip such lambdas when resolving
the returns' references, but it'd be more complicated and still useless
since non-local returns are impossible in such lambdas
(relevant parameter is noinline)
#KT-22900 Fixed
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
This results in more diagnostics usually, but allows library authors to
avoid annotating everything in each experimental class with the marker
(only the class needs to be annotated now)
#KT-22759
- Prohibit non-modifier-like calls on kotlin.suspend
- Add warning on modifier-like calls to anything but kotlin.suspend
#KT-22766 In Progress
#KT-22562 In Progress
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
Yan Zhulanow