The original case provoked forking a constraint system which isn't supported in K1 (K2 only). If the captured type is recursive, then type parameter's upper bounds may break subtyping due to substitution the current captured type again, into a recursive type parameter.
Note that we already have special logic for recursive captured types. See `isTypeVariableAgainstStarProjectionForSelfType`.
^KT-52782 Fixed
Consider a function `run2` that has 2 lambda arguments called in place.
We don't know the order in which they're called, so here:
var x: Any? = something
run2(
{ x = null },
{ x as String },
)
// <--
it's not correct to simply `&&` the statements together, as that would
produce `x is Nothing? && x is String && x is Any?`. Instead, statements
should be grouped by assignment first, and different groups are `||`-ed.
This means in the above example we now get `x is Nothing? || (x is Any?
&& x is String)` == `x is String?`.
For example:
foo(
// `if` joins A & B
if (condition)
run { ... } // A
else
run { ... }, // B
run { ... } // C
) // `foo` unifies `A & B` and `C`, so if it is not resolved itself,
// further `if`s, `when`s, safe calls outside it, etc. continue
// building the correct type predicate until the next completed
// call.
^KT-44512 Fixed
In DeserializedClassDescriptor and MemberDeserializer, only the
`contextReceiverTypeList` field was used, and not
`contextReceiverTypeIdList` which is used when `-Xuse-type-table` is
enabled. The convention is to use a bunch of utilities declared in
`protoTypeTableUtil.kt` which deal with both methods of reading types.
Also, simplify the deserialization code in FIR (which was correct for
some reason).
- Get rid of SPECIAL mode (just left REGULAR and class-related instead)
- Clear naming
- Restore contexts after lambda/callable reference are processed
The test has been failing before this change because after
callable reference is resolved, its tower data context has been left
erroneously in the SPECIAL-related entry
If we want to analyse some function's call, we need to know about its
contracts, otherwise resolving the following code would be broken.
Computing return type of function is a prerequisite to using it in any
sensible way, so it's the best place to resolve it to CONTRACTS
KT-50733
Using `ownerLookupTag` might be wrong in case of private constuctors
of inner classes: their owner is an Inner class, but expected
dispach receiver is Outer
- use-site should be contained within the class that owns callee symbol
- class-representative of dispatch receiver value
should be exactly the same as a container class of a callee (not its subtype)
It leads to further infer type variable into those upper bounds which is forbidden
Substituted upper bounds is ok because specific substituted types came from constraints of other proper positions, or if specific substituted type is from declared upper bound too, then there should be another declared upper bound with no substitution
^KT-51464 Fixed
^KT-47986 Fixed
Ilmir Usmanov