This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
A wrapper block was introduced as a part of fixing KT-59748, but was
assigned a real source, which had `getOrBuildFir` confused because
of the incorrectly built `KtToFirMapping`
It is relevant for:
- `if`, `when` expressions with an assignment as a single expression
- Kotlin code fragments,
when the assignment is being analysed as a single expression
in the fragment
^KT-66411 Fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: 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
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
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
- This adds KDoc reference resolution tests for callables in nested and
inner classes, overloaded functions, and private callables.
- Private declarations are visible in KDoc from outside their containing
classes. This is in line with K1 KDoc behavior.
^KTIJ-22324
`FirSafeCallExpression` does not implement `FirResolvable`, so we need
to unwrap it to correctly resolve calls like `foo?.bar()` when `bar` is
a lambda with receiver parameter or a functional type property
^KTIJ-27434 Fixed
This commit also fixes a missing symbol for KtScriptInitializer
and some symbol pointers
Many tests marked as 'DO_NOT_CHECK_NON_PSI_SYMBOL_RESTORE'
due to KtFirFileSymbol#createPointer logic – the pointer can
be created only for PSI
^KT-61451
^KT-61887
^KT-62626 Fixed
^KT-62693
To properly resolve qualifier parts in the middle,
we need to resolve the whole qualifier to understand
which parts of the qualifier are package or class qualifiers.
And then we will be able to resolve the qualifier
selected by the user to the proper class, package or callable.
^KT-59189
1. Optimize it by removing a tower data context collection (KT-59189)
2. Rework the behavior, so it simulates the tower resolve by returning the set of symbols only from the first tower level, which is not empty
^KT-59189 fixed
It's very slow and leads to performance problems (see KT-58125)
Instead, we do the following:
- For a fully resolved type qualifier, when we want to resolve its part,
we are looking for the corresponding symbol by traversing nested classes
bottom up.
- For an error qualifier, we are trying to resolve the maximum possible
qualifier in the types transformer where all the type scopes are
already available.
^KT-58125 fixed
Egor Kulikov