K2: Complete property-candidate before starting invoke resolution

Before this commit, for property candidates in K2 their types wasn't
inferred/susbtituted properly.

So, when candidate for fooBar.liveLoaded.invoke() was created,
the type of `fooBar.liveLoaded` was just X type parameter for which
there is no any `bar()` functions in its member scope.

While proposed semantics is a bit different from K1, where
both property and invoke candidates are united into common system,
it doesn't contradict to the specification (https://kotlinlang.org/spec/overload-resolution.html#callables-and-invoke-convention)
which says explicitly that invoke-convention should be desugared as
`r.foo.invoke()`, thus `r.foo` should be completed independently.

Also, this strategy supports some reasonable use-cases like KT-58259
while it's still a breaking change but for more artificial-looking
situations (see KT-58260) and should be passed through
the language committee.

The changes in stubTypeReceiverRestriction* tests looks consistent
because of how `genericLambda` now works
(with full completion of property call).
NB: The code is going to be red once KT-54667 is fixed and also there's
already similar diagnostic in K1 (INFERRED_INTO_DECLARED_UPPER_BOUNDS)

^KT-58142 Fixed
^KT-58259 Fixed
^KT-58260 Related
This commit is contained in:
Denis.Zharkov
2023-04-24 12:27:47 +02:00
committed by Space Team
parent 481becb342
commit 7b46c59d57
17 changed files with 191 additions and 68 deletions
@@ -0,0 +1,20 @@
// ISSUE: KT-58259
interface Box<T> {
val value: T
}
interface Res {
operator fun invoke() {}
}
val <X> Box<X>.foo: X get() = TODO()
fun foo(p: Box<Res>) {
p.value.invoke() // OK
p.value() // OK
p.foo.invoke() // OK
// Error in K1, OK in K2
p.foo()
}