- 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
- 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
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
If an unused setter parameter was replaced with an underscore ('_'),
it had a special name in the stub ('<anonymous parameter 0>'). The text
version of the stub inserted it as is, leading to an extra
'PsiErrorElement'.
^KTIJ-28194 Fixed
One of the previous commits moved calculation of diagnostics from
FirAnalyzerFacadeinto the separate test service, so it should be altered
in AA tests too
...by honoring accessors' visibility
We need a special handling for backing field visibility,
e.g., lateinit, const, or JvmField, but that's not the case
for accessors' visibility.
^KT-64937 fixed
This MR fixes two independent issues causing build failures when using Kapt in combination with the Kotlin serialization plugin (and, very likely, with other plugins as well):
Kapt applied compiler plugins twice, causing errors similar to the one described in KT-65006
Kapt failed to generate @Metadata annotations for plugin-generated companion objects because the corresponding SLC missed containingFile needed for generation of method and class signatures
Merge-request: KT-MR-13970
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
Denis.Zharkov