- 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
Extension receivers are currently implicitly noinline, and changing that
would require modifying the syntax to allow marking them noinline or
crossinline.
^KT-5837 Open
^KT-25787 Fixed
^KT-47965 Fixed
^KT-50107 Fixed
^KT-52403 Fixed
Sometimes, it might be called before type parameter bounds are initialized
or even before the symbols are bound to FIR
In such cases, we just assume it makes sense to create DNN there
class JavaSuperClass {
// members impls with special signature, but it doesn't override any Kotlin specials
}
class KotlinInterface {
// special members
}
class JavaSubClass extends JavaSuperClass implements KotlinInterface {
// we should obtain members from JavaSuperClass with their Kotlinish
// signature, not the Java one
}
That issue might be fixed via changing
TypeVariableMarker.shouldBeFlexible at ConeConstraintSystemUtilContext
but this and some other tricks have been added because of incorrect
handling of constraints where type variable has a flexible bound
^KT-51168 Fixed
Dmitriy Novozhilov