Creating and disposing CoreApplicationEnvironment on each call leads to
problems with parallel builds, while KotlinCoreEnvironment
avoids disposing application environment in case of parallel builds.
#KT-23694 fixed
There was an exponential complexity in case we have a chain
of nested LexicalScopeWrapper instances:
we were walking through the chain and on each step running
the algorithm recursively.
Such a case is possible in scripts where each line contains LexicalScopeWrapper
The fix looks safe to me because delegate was used there
for checking !is ImportingScope && !is LexicalChainedScope
In all other means, being recursively run the algorithm does the same job.
#KT-22740 Fixed
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.
Alexander Udalov