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.
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
Some of IDEA services (like in `com.intellij/execution`) was copied,
because they are used in tests but jars with them compiled with
jdk 11 and we run our tests on jdk 8, so their bytecode can not
be read
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
`throw` is not needed in this case, because `error(...)` already
raises exception (so `throw` is unreachable). Also after previous
commit compiler reports `UNREACHABLE_CODE` warning on such `throw`
This is needed for the inliner: since the information about Kotlin type
of the bound receiver is nowhere in the output binary, the inliner will
have no clue how to box inline class values. Moving the boxing outside
the object means the inliner doesn't need to know about it; from its
point of view, the captured value has type `Any`.
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
This avoids an extra call to 'analyze', which is rather costly.
Update debugger testData: Constant condition
elimination now performs DCE more consistently.
pyos