When lazy resolve is involved, type bounds can be in an unresolved
state (e.g. `FirUserTypeRef` instead of `FirResolvedTypeRef`). To
enforce the resolve, we use `resolvedTypeBounds` where it might be
important
^KTIJ-20618 Fixed
There just should be a different facades for cases
A<T1, T2> and foo<T1, T2>()
Test data has changed for type alias constructors since previously,
it was working by mistake because of assumption that type alias arguments
are linearly mapped to the type parameters of the corresponding constructors
^KT-50703 Open
In this commit we add nullability to upper type of a substituted
constraint in the situation like (Stub<_L> <: SomeType),
where _L is fixed to nullable Stub<_L>?.
We have to change this constraint to L <: SomeType? and not to
L <: SomeType as before, otherwise nullability become broken
(direct substitution of Stub<_L> to L is illegal here).
#KT-50470 Fixed
Some existing tests start failing after previous commits adding @Exact
attribute to `?:`
They have a form:
var x: String? = nullable()
if (x == null) {
x = nullable() ?: "" // considering @Exact the whole elvis is inferred to nullable from expect type
}
x.length // should be smart cast
Previously, it was obtained from expected type of a variable being assigned,
but it's better to use the type of resulting expression
Initially this part was brought in 4ab0897d7d,
but as we see in commit message and tests it was all about unit-coercion
If some java class has multiple supertypes then we need to collect
overriddens from all those types directly, even if superTypeScope
(which is FirTypeIntersectionScope in this case) returns only
one symbol from one of this types (not intersection one)
This is needed to proper enhancement in cases when some type occurs
multiple times in supertypes graph with different nullability
of arguments:
class ConcurrentHashMap<K, V> : AbstractMap<K!, V!>, MutableMap<K, V>
If we try to find method `get(key: K): V` supertype scope returns
`AbstractMap.get(key: K!): V!` (because it actually overrides
`MutableMap(key: K): V?`), but we need to get both symbols to
properly enhance types for `ConcurrentHashMap.remove`
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Roman Golyshev