For some reason, this logic was a bit different in JVM (FunctionCodegen)
and JS (FunctionBodyTranslator). For example, in JS the
EXPECTED_FUNCTION_SOURCE_WITH_DEFAULT_ARGUMENTS_NOT_FOUND diagnostic was
reported even in the case when no expected function was found for the
actual function at all, which made it quite difficult to write
multiplatform sources for JS stdlib where it both should be compiled as
a part of the multiplatform project, and by itself (suppressing
NO_ACTUAL_FOR_EXPECT): in the latter case, the new error must have been
suppressed everywhere as well
#KT-21913
When default argument value was present in the expected declaration, we
did not correctly serialize that fact to the metadata for the actual
declaration (`declaresDefaultValue` was used). Therefore, it was
impossible to use that actual declaration without passing all parameter
values in another module, where it was seen as a deserialized descriptor
#KT-21913
Fake overrides for abstract members from expected classes should become
non-abstract (final, in fact) in non-abstract expected subclasses
#KT-22031 Fixed
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 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.
1. Do not save a ClassLoader reference inside the context, as we don't use it anyway after evaluation.
This is to avoid custom ClassLoader nesting.
2. Do not use 'findClass()' as it caches the loaded classes and always returns the first evaluated class if it's in cache.
There is no Messages dialog in newer versions of IDEA/Android Studio in which the error messages were mapped before. The new Build window shows only the original locations, so now we need to replace Java file diagnostics with ones mapped to Kotlin source files.
The side effect is that diagnostics on the same locations are automatically merged.
Placing location table inside .java file triggers annotation processor to run on each line table modification (even when the stub declarations themselves are the same). So we move it to the separate file.
Store kapt configurations instead of classpath files in the tasks
Delay wrapping kapt subplugin options to task execution (when the
classpath can be safely resovled)
Issue #KT-18821 Fixed
Mikhail Glukhikh