* Support flags with any value (not just Boolean)
* Support all flags by parsing arguments in KotlinFacetSettings, instead
of manually listing known flags
#KT-19210 Fixed
In the test case, the problem was that Foo.a's type was resolved to the
_class A_, which was written to metadata on JVM instead of the class
AImpl with typealias A as an abbreviation. This metadata was incorrect
because there's no class A from the JVM compiler's point of view; that's
why the error "cannot access class A" was reported
#KT-19151 Fixed
If 'this' (implicit or explicit) was used as an extension receiver,
and the corresponding call required a smart-cast,
this information was effectively lost in "old" resolution & inference,
but is required by "old" JVM BE to generate proper CHECKCASTs.
This makes sense for non-floating-point primitive type
(boolean, char, byte, short, int, long):
floating-point types use specialized versions of 'areEqual'.
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
Alexander Udalov