Revert "`KotlinCoreEnvironment`: set `ideaCompatibleBuildNumber = "173.1"`"
This reverts commit d3321cc77a6b55d8b8ff3c3a16473f2f3b378533.
Revert "`JvmFacade`-related tests repair"
This reverts commit faeacdd17d37a4d733b686f3a1d5e8fc6ea54d79.
Revert "Register new service and EPs added in 173"
This reverts commit 5d227c0e714c1b4316e7b8daca1f208ee423f448.
NB we use 'Intrinsics.areEqual(Double, Double)' and
'Intrinsics.areEqual(Float, Float)', because right now we take
nullability from the inferred type of the expression (which is 'Any?' in
the test cases).
We should probably reconsider this in case of more exact information
available from the data flow analysis, e.g., in case of
fun test(x: Any?) =
x is Serializable && x is Double? && x == 0.0
We statically know that 'x' is not null in 'x == 0.0' (although it's
neither nullability of it's numeric type 'Double?' nor the nullability
of the inferred type 'Any?').
There might be some edge effects in the performance related to byte code
size and preventive unboxing and so on.
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
Condition was too strict
if @JvmDefault implicitly hidden by class in inheritance.
Diagnostic is redundant cause there isn't breaking
change depending on interface method generation strategy and
delegating stub generation in inheriting class.
Condition was too strict if we actually make super call
through super class. Diagnostic is redundant cause there isn't breaking
change depending on interface method generation strategy.
This can happen e.g. if all supertypes were on the cycle (A : B, B : A)
-- then SupertypesLoopChecker will cut all supertypes that are on cycle,
leaving set of supertypes empty.
Some clients in the compiler are not ready to work with empty list of
supertypes -- notably, CommonSupertypes.
^KT-23029 Fixed
Private suspend functions need to be generated as package-local, since
they are called from their continuations.
However, this means that they can be called from Java, which breaks
their private visibility.
Adding synthetic to them fixes the issue.
#KT-17584: Fixed
We're suspecting that the culprit of such errors is race condition on
'supertypes' in AbstractTypeConstructor, when it is created using
'LockBasedStorageManager.NO_LOCKS'
- Do not longer call hashCode on java/lang/Object but do this
on statically checked type.
- Do not longer call Intrinsics.areEqual but use directly
equals method on statically checked type.
Fix of https://youtrack.jetbrains.com/issue/KT-12330
Treat them like lambdas. This means:
1) Like local suspend lambdas, which become "non-suspend" after creating
jvmSuspendView, they do this as well
2) They both are generated with the same codegen.
3) They are treated differently only on front-end side.
#KT-20364: Fixed
Nicolay Mitropolsky