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
Context without expected type became redundant after synthetic
call resolving was added for inference of `if` expression type
`isStatement` flag removed, because it was effectively unused
This code can be invoked early, during body resolution and before the
fact that a property has backing field (which is only known for certain
after body resolution, because an implicit 'field' identifier may be
used). Since split annotations are cached until the end of the program,
they may end up on incorrect elements in the bytecode (or disappear
completely) as in KT-29507 or KT-28182.
Because the FIELD target has the lowest priority among implicit
annotation targets (see TARGET_PRIORITIES), it's safe to always assume
that FIELD is a valid target when splitting annotations. This only
changes the way annotations are split in case of incorrect code, as
changes in test data show.
#KT-28182 Fixed
#KT-29507 Fixed
Add some classes to hierarchy of `ESValue`:
- `ESReceiver` -- representation of receiver
of lambda function
- `ESDataFlow` and `ESDataFlowReceiver` -- little refactoring of entities
that holds information for DFA (description in comments in code).
Also add kdoc to classes of `ESValue` hierarchy
Previously only `VariableDescriptor` was key of `ControlFlowInfo`.
Now it's generic parameter `K: Any`, so there is a possibility of using
different object's inside CFA
Alexander Udalov