The type of the default lambda may be a subtype of the parameter type,
so we can't really generate our own coercions at all as we don't know
the precise Kotlin type of the `invoke` method.
1. receivers should be evaluated before named arguments;
2. just because an argument has no side effects doesn't mean it is not
affected by the other arguments' side effects - in that case it
should still be evaluated in source order.
#KT-47660 Fixed
Now this:
class C {
val x = something
val y by x::property
}
is *exactly* the same as this:
class C {
val x = something
val y get() = x.property
}
(plus a `getY$delegate` method)
E.g. a statement like
var x by ::y
is semantically equivalent to
var x
get() = y
set(value) { y = value }
and thus does not need a full property reference object, or even a field
if the receiver is not bound.
#KT-39054 Fixed
#KT-47102 Fixed
Default function stubs have dispatch and receiver parameters, but
inline class methods are static by design with receivers as ordinary
parameters. So, take these parameters and set them as receivers during
lowerings.
#KT-46230: Fixed
In the stdlib implementation, render "!" if the type is only
nullability-flexible. Otherwise, render "($lower..$upper)".
Note that full kotlin-reflect has a much more complicated logic (see
`DescriptorRendererImpl.renderFlexibleType`) that renders things like
`(Mutable)List` and so on. It is not a goal of the stdlib implementation
to replicate all of that, since it requires copying a large amount of
code, namely the entirety of `JavaToKotlinClassMap` to map Java class
names to Kotlin.
The proper support will come in KT-15518, but that would be a breaking
change even for stable Kotlin without kotlin-reflect. Before that issue
is fixed, represent Nothing in types with the Void class, and use a flag
in the no-reflect implementation to remember that it's not actually the
Void class itself.
#KT-39166 Fixed
Otherwise an invalid type is constructed which causes kotlin-reflect to
crash, and stdlib implementation to render the type incorrectly. The
reason is that suspend functional types are not properly supported in
reflection. Once they are supported, this error can be removed.
#KT-47562
Instead of requiring it to be on the compiler classpath.
This will make it much easier to profile the Kotlin compiler daemon in
Gradle, by just specifying a compiler argument instead of also manually
patching the compiler jar.
The corresponding JavaSymbolProvider currently is unable to
see the `Foo` class, because under the hood it uses
`JvmDependenciesIndexImpl` which doesn't know about the corresponding
.java file because it is created for m2-module `project`
I wasn't able to fix it yet
Ivan Kochurkin