Motivation of using dispatch receiver type when calculating method owner
was discussed here: https://github.com/JetBrains/kotlin/pull/3054
However, this is incompatible with type erasure of non-reified type
parameters on inlining (which will be done in future). Consider the
code:
```
inline fun <T> f(arr: Array<T>, p: (T) -> Int): Int = p(arr[0])
fun box() = f(arrayOf("abacaba"), String::length)
```
After inlining and erasure, the type of `arr[0]` is `Any`. Thus, when
calculating owner of `String::length` we would have `Any` instead of
`String` if we used dispatch receiver type.
Note, that this change affects bytecode instruction that invokes
method, but does not change which method is being invoked.
- For synthetic calls
- For delegated constructor calls
Also, I checked that for each toResolvedReference() (beside annotations)
that converts candidate to the resolved reference,
we run `runPCLARelatedTasksForCandidate()` in the same context.
^KT-65103 Fixed
It's been used only for regular function call nodes resolution,
so I made it more explicit.
The main idea behind this change is ResolutionMode hierarchy
simplification and the kind of statement
that "AugmentedAssignmentCallOption" is only relevant to calls.
Instead, CallResolutionMode is introduced that is only used for
`transformFunctionCallInternal` call sites.
- Move it out of the ContextDependent hierarchy
- Get rid of many controversial checks that were necessary because
Delegate was a ContextDependent inheritor
- Actually fix semantics for lambda processing
Previously, lambdas as delegate expression were not being analyzed
thus leading to an exception (see KT-64635), and this change
forces analyzing them in the same mode as ContextIndependent
(thus `{}` made by default `() -> Unit` leaving to DELEGATE_SPECIAL_FUNCTION_MISSING)
Before this change, new test was failing with an exception.
I've analyzed all `is ContextDependent` and it seems that none of them
is relevant to delegates.
^KT-64635 Fixed
Build failure was introduced by `9b786d35`,
where I forgot that typealiases exist.
^KT-64891
^KT-65336 Fixed
Merge-request: KT-MR-14087
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
When encountering multiple available same named types,
resolve all of them together with corresponding extensions.
This aligns well with the current resolve behavior of classes
with the same name (see `SameNameClassesFromStarImports.kt`)
Also, add extra test for resolving the ambiguous type without
the extension function. The behavior is the same - resolve to the
both classes.
Render caret names in resolve testData, so that we don't have to guess
the indices of the carets;
it makes the multi-caret testData less error-prone.
Relevant for KT-65152 and KT-62695
The solution is not complete, since resolution of KDocs is not
fully specified and is rather tricky.
Many more corner cases are to be expected.
This solution should at least give some groundwork for the future
improvements/fixes of the resolver.
^KT-62695 Fixed
It's a part of implementation; it will be required to properly navigate
from resolved extension function to its receiver type, since receiver
type cannot be properly inferred from the function symbol itself
Make sure that, when ambiguous, both the package
and the callable/class/property are resolved from
KDoc reference.
Do a slight refactoring of `KDocReferenceResolver`
This behavior is also true for K1
Allow multiple carets to be used in reference resolve tests.
Adjust the testdata for the only test case which has actually
had multiple carets in it.
Required for KT-65152 and KT-62695
Add possibility to `ExpressionMarkerProvider` to get all the carets
from the file.
Use it in `AbstractReferenceResolveTest`, but not check all the carets
yet.
Required for KT-65152 and KT-62695
Instead of relying on UNRESOLVED_REFERENCE directive for the whole file,
just render the unresolved reference right in the .txt testdata
This will allow to introduce multi-caret resolve testdata more naturally
Required for KT-65152 and KT-62695
FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
vladislav.grechko