We should never do that, because otherwise we can get unexpected result.
Example for input constraint: C(in String) <: T.
If we run usual subtyping algorithm, then we get 2 constraints:
C(in String) <: T and T <: String.
Of course such system has contradiction.
We prefer denotable types when we solve constraint system.
I.e. if for T we have not equality constraint with captured type we can approximate captured type to denotable type.
This is bad idea, but this is how it works in old inference.
Now we just save old behaviour.
Future plan: fix checks where we get unfinished resolved calls.
- report WRONG_NUMBER_OF_TYPE_ARGUMENTS
- make integral types work again: IntegerValueType is represented as {Int & Byte & Short & Long} in the constraint system
FOR_LOOP_ITERATOR
- temporary variable for for-loop iterator
FOR_LOOP_VARIABLE
- `x` in `for (x in xs)`
FOR_LOOP_IMPLICIT_VARIABLE
- temporary variable for for-loop with destructuring, e.g.:
for ((x, y) in xys)
=>
for (tmp in xys) {
val (x, y) = tmp
}
Initialization of companion object members (e.g., delegate properties
using provideDelegate convention) can depend on property metadata array,
which in turn can be initialized before other class members.
#KT-18902 Fixed Target versions 1.1.5
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
- 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)
Stanislav Erokhin