Switching to in-process to avoid compilation warnings caused by introduced
daemon interface changes.
Switching to the gradle plugin 1.1.3 causes jansi incompatibility in
in-process compilation mode, so disabling jansi usage to avoid it.
* Do not read protos for descriptors of stdlib and kotlin-tests
repeatedly
* Parse libraries lazily in inline, so that when no inline function
exist in a test, we won't parse huge kotlin.js file
* Speed-up source map parser
- Exception on dynamic type in typealias argument expansion
#KT-18858 Fixed Target versions 1.1.5
- Wrong report location for repeated annotations in typealias arguments
#KT-18940 Fixed Target versions 1.1.5
- Don't drop type annotations for dynamic type
#KT-18944 Fixed Target versions 1.1.5
No test added because it would involve running javac 9 and because tests
run JavaBuilder in the same process, this would require either a new
module in our project with dependency on JDK 9 (which would require
everyone to install JDK 9), or complex code that runs javac in another
process
Also report the "named does not read unnamed" error, which was not
possible previously because we wouldn't be able to read anything from
kotlin-stdlib (because it was added to the unnamed module by default)
Essentially, the logic that was previously in
JvmModuleAccessibilityChecker.diagnosticFor, is moved into a new
abstract method JavaModuleResolver.checkAccessibility, which is
implemented differently in the compiler and in the IDE. In the compiler,
we use our JavaModuleInfo and JavaModuleGraph, as previously. In the
IDE, we use intellij's PsiJavaModule and JavaModuleGraphUtil.
This fixes strange behavior in IDE where some modules could be observed
in an invalid state. The cause of that was the JavaModuleGraph instance
caching modules in IdeJavaModuleResolver, which is a project component.
Moreover, this will allow to report an error "named module does not read
unnamed module" in the compiler, and avoid reporting it in the IDE (see
the comment in IdeJavaModuleResolver about that)
When we have some custom implementation of Comparable, it's important
that we compare values exactly as 'lowBound <= a && a <= highBound'.
Make sure that evaluation order and compareTo calls match for
optimized and non-optimized case.
As of Kotlin 1.0 and 1.1, expression 'a in x .. y' is considered
equivalent to 'x.rangeTo(y).a', and should be evaluated in the following
order:
1. x
2. y
3. a
4. compare x with a
5. compare y with a (if needed)
It's safe to upcast integer types to Long,
floating-point types to Double.
So we don't have to create a range instance for cases such as
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a .. b
which is equivalent to
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a.toLong() .. b.toLong()
DUP_X1; POP = SWAP
p1_a; p1_b; SWAP = p1_b; p1_a
where p1_a, p1_b are instructions without side effects pushing value of
size 1 on stack.
E.g.: ACONST_NULL; ALOAD 0; SWAP = ALOAD 0; ACONST_NULL
NOP; NOP = NOP
DUPn_Xm instructions implicitly depend on elements directly under stack
top (which are not "copied", but still required). We can't analyze them
precisely now, and should skip methods containing these instructions.
Fortunately, we didn't generate these instructions under POP before,
but with new range check code generation and constant conditions
elimination such combination of instructions becomes possible.
Provide BoundedValue-based implementation of InExpressionGenerator,
test it on range of comparable values.
Drop unneeded test (range of comparables is already tested by
ranges/contains/inComparableRanges.kt).
Ilya Chernikov