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
Crossinline lambdas *can* be inlined into objects, but don't *have* to;
the correct place should be determined from the context, not from the
parameter.
1. the `primitive == object?.something` fusion should not apply to
`primitive.equals(object?.something)` because it can't;
2. coercions to Int are there for a reason - don't remove them;
3. better optimize `primitive == object?.something` -- the result
should be subject to if-null fusion, so it needs to have a specific
pattern that resembles safe calls.
#KT-47597 Fixed
Meaning, they never need continuation objects. This shouldn't affect
correctness (if the assumption is valid, the continuation object
should always have been removed in the end), but the phantom
continuation sometimes left behind unused accessors (and in case of
inline function references, those accessors would refer to non-existent
functions) - see the modified test and Kotlin/kotlinx.coroutines#2769.
Note that resulting SAM method
public final method accept(p0: java.lang.Object): void
has a signature less specific than the resulting bridge method
public synthetic bridge method accept(p0: X): void
pyos