The case is when we have a simple type constructor
(not array nor collection) and type is not raw:
A<T1, >..A<T1>?
Actually these types are almost equal besides of nullability,
but we create and resolve two different simple types,
they have different arguments' lists, etc.
The idea is to add NullableSimpleType subclass with delegate
to another simple type
It should help a lot both with common cases and with corner ones:
flexibles types in spark for Function22 having exponential size
because of its flexibility
#KT-14375 Fixed
#KT-14323 Fixed
Design decision: if the field for a companion object should have
non-public visibility, generate it with @Deprecated annotation in
language version 1.2.
TODO: generate it with proper visibility in 1.3 and later.
KT-11567 Companion object INSTANCE field more visible than companion object class itself
The error message is removed and is replaced with a code that adapts
inline suspend functions produced by the old compiler with the
suspension markers that new compiler expects.
There's no point in adding JDK (mock or full) roots to it, as well as
stdlib/reflect/test (they are loaded by the parent class loader, created
in ForTestCompileRuntime)
The problem is that now that the local delegated property metadata is in
the $$delegatedProperties array of the containing class, the access to
it from code calling an inline function with a local delegated property
is illegal.
Currently it seems to be a lot of work to support this rather rare case
properly (see the comment in ExpressionCodegen.getVariableMetadataValue)
so we postpone it and return the old behavior of using the anonymous
KProperty subclass for metadata
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.
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
- 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
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)
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()
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).
Denis Zharkov