Follow-up of 9b3e17f0. There we decided to complete call if a type
variable from a return type has proper lower constraints, now we refine
this rule wrt `Nothing`-like constraints to avoid inferring type variables
to Nothing, which is quite useless
#KT-30370 Fixed
A lookupswitch or tableswitch can be used if all conditions are equality
checks to constants. To be more specific, it can be done if:
1. All conditions are CALL 'EQEQ(Any?, Any?)': Boolean
2. All types of variables involved in comparison are in the same group
of Char/Byte/Short/Int, String or enum.
3. All arg0 refer to the same value.
4. All arg1 are IrConst<*>.
Change-Id: Ifd7cb618395f6c5cc64601018b446f0bb7f5891c
The problem is that delegated properties resolve two calls together:
`getValue`/`setValue` with a common receiver, which can contain
callable references. For each completion new anonymous descriptor
was created and caused "rewrite at slice" exceptions later.
Now there is a little hack to check that during one inference session
we don't complete one call more than one time.
More correct fix would be to explicitly specify common receiver for
inference session but it requires quite big refactoring, which will
be done later with a whole refactoring of the common solver
#KT-30250 Fixed
Consider common supertype of `S` and `Nothing`, where `S` has nullable
upper bound or it's flexible. Before the fix, result was `S?`, which
is correct but too conservative. Now, we'll preserve nullability of
resulting type if it's already nullable.
This happened because we were failing to find path of not-nullable
types from `Nothing` to `S`, which should obviously exists by
semantics of Nothing
Consolidating these into IrStringConcatenations allows the backend to produce efficient code for string concatenations (e.g., using StringBuilder for JVM).
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
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
Mikhael Bogdanov