This was broken in c1ab08c8ce where we started to represent KClassValue
as a ClassId of the referenced class + number of times it's been wrapped
into kotlin.Array. Local classes do not have a sane ClassId, so in this
change we restore the old behavior by representing KClassValue with a
sealed class value instead
#KT-29891 Fixed
Even though acquire/release pattern guarantees memory visibility across
threads, it doesn't prevents concurrent access to critical section (i.e.
to force-resolve of the corresponding body).
This can lead to multiple resolution passes over one and the same PSI in
IDE, which, in turn, leads to 'rewrite at slice'-exceptions. See
KT-30030 for case description and details.
^KT-30030 Fixed
Consider the following situation:
```
class Inv<T>
typealias A<K> = Inv<K>
typealias B<V> = Inv<A<K>>
fun <U> materialize(): B<U> = TODO()
```
Type `B<U>` is expanding to `Inv<Inv<U>>` and for this type `B<U>` and
`Inv<A<U>>` are abbreviated types, but due to a bug we forgot to make
substitution for `Inv<A<U>>` and were getting abbreviated type
`Inv<A<K>>` where `K` is a type parameter from the typealias declaration.
This bug didn't affect subtyping anyhow but the incorrect type was
serialized and caused problems during deserialization as there wasn't
`K` in deserialization context.
#KT-24964 Fixed
#KT-20780 Fixed
#KT-20065 Fixed
#KT-28236 Fixed
#KT-21775 Fixed
Augmented assignment operator (e.g., '+=') can be resolved to simple
function call ('plusAssign'). In that case, augmented assignment LHS
can be an arbitrary expression, and may have no associated ResolvedCall.
For example:
(a as MutableList<Int>) += 42
Note that it can happen only in case of augmented assignment operator
convention resolution, because all other forms of assignment-like
operator desugaring require some kind of 'store' operation
(property setter, 'set' operator for array element expression, etc),
and should resolve to some combination of calls.
In that case we simply generate LHS on 'load', and throw assertion on
'store'.