Instead of trying to access a missing field `Foo.foo`, call the
synthetic accessor `Foo.access$getFoo$cp` which, as per previous commit,
no longer contains the lateinit assertion
#KT-21862 Fixed
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
This fixes the most common (and rather annoying) bug in augmented
assignment desugaring with collection element receiver.
Fix is somewhat hackish: introduce an intrinsic for MutableMap.set,
thus bypassing discrepancies in 'get' and 'set' call generation.
Fixing it properly requires design decisions for corner cases where
ad hoc augmented assignment desugaring with collection element receiver
"accidentally" works, producing identical objects and vararg arrays for
arguments of 'get' and 'set'.
Previously they were trying to call constructor (incorrectly) for
recursive calls. This is redundant, since this.invoke creates one
automatically.
In addition, support callable references to recursive local suspend
functions.
#KT-24780 Fixed
[JS IR BE] Runtime fixes
* Do not generate external declarations for IR BE
* Move `arrayToString` helper function out of shared JS stdlib
* Fix arrays type check for IR BE
Sometimes, state-machine, generated in inline functions with
crossinline parameter, is transformed, since all usages should be
renamed.
However, this is wrong: in this case, we will have state-machine
inside state-machine.
This fix addresses the issue.
#KT-25893 Fixed
Initial problem is started in `capturedBoundReferenceReceiver` method
where we assume that bound receiver is captured for usual call.
Note that if method is inline then we don't pass actual name reference
receiver, but pass special CAPTURED_RECEIVER_FIELD, which is then
is used to find special instructions during inline and fold several
instructions in `foldFieldAccessChainIfNeeded`.
As a result, we got unboxed reference receiver for inline call, which
caused CCE and to fix it we should box receiver one more time during
inline
#KT-28188 Fixed
Getter of a primary value of an inline class belongs to the box class.
Its arguments should not be unboxed when the method is called.
However, its result might require boxing if it's an inline class value.
When we have an internal primary value, there's no getter method.
In fact, we can use box/unbox methods for inline class directly
(don't forget to box the result, it may be an inline class type value).
#KT-26748
Note that this commit doesn't fix case when some inline class over
`Any` is returned from a lambda, it'll be fixed further as part of the
#KT-27586
#KT-27737 Fixed
Return type is not needed for checking overloads, but querying it may
involve resolving function bodies, which usually happens after overload
checking (see LazyTopDownAnalyzer.analyzeDeclarations) and at this point
can lead to incorrect BACKING_FIELD_REQUIRED value being computed for
some properties (see KT-27895)
#KT-27895 Fixed
Alexander Udalov