- 12 7月, 2017 4 次提交
-
-
由 Alexey Tsvetkov 提交于
Before this change jansi was used by the compiler, unless "kotlin.colors.enabled" is not set to false. This caused multiple issues in different build systems, where newer or older version of jansi could crash the JVM since it uses native code. The following short term solutions were discussed: * Set "kotlin.colors.enabled" to false where jansi is not needed (basically in any build system). * Set "kotlin.colors.enabled" to true where jansi is needed, and use it only when the system property is set to true. Escaped codes are only needed in CLI tools (kotlinc, REPL), so the second solution is preferred (less places to set the property). #KT-17031 fixed #KT-18874 fixed #KT-18927 fixed
-
由 Kirill Rakhman 提交于
-
由 Alexey Andreev 提交于
When inliner reads function's body from other module, it performs substitution _ -> moduleAlias. However, local alias can't be used for this purpose, since call site can be in public inline function itself, so the correct substitution would be -> _.$$imports$$.alias
-
由 Mikhail Glukhikh 提交于
Related to KT-14799
-
- 11 7月, 2017 9 次提交
-
-
由 Dimach 提交于
-
由 Ilya Chernikov 提交于
since it breaks the compatibility and doesn't actually help - the problem with NoClassDef Unit is apparently elsewhere.
-
由 Ilya Chernikov 提交于
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.
-
由 Mikhail Glukhikh 提交于
Related to KT-18830
-
由 Toshiaki Kameyama 提交于
-
由 Toshiaki Kameyama 提交于
So #KT-18074 Fixed
-
由 Toshiaki Kameyama 提交于
-
由 Alexey Andreev 提交于
* 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
-
由 Dmitry Petrov 提交于
- 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
-
- 10 7月, 2017 27 次提交
-
-
由 Nikolay Krasko 提交于
-
由 Nikolay Krasko 提交于
#KT-18863 Fixed
-
由 Nikolay Krasko 提交于
#KT-18805 Fixed
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Alexander Udalov 提交于
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
-
由 Alexander Udalov 提交于
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)
-
由 Alexander Udalov 提交于
-
由 Alexander Udalov 提交于
-
由 Alexander Udalov 提交于
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)
-
由 Alexey Andreev 提交于
-
由 Dmitry Petrov 提交于
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.
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
ICONST_0; I2L -> LCONST_0 ICONST_1; I2L -> LCONST_1
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
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)
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
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()
-
由 Dmitry Petrov 提交于
-
由 Dmitry Petrov 提交于
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
-