Namely, in the previous commit we merged two
(LOW and HIGH priority default start import scopes) into the single one
For more explanations, please look at the previous commit
Calls to extension functions imported from objects have implicit
dispatch receivers, but those receivers are not present in the code
and should not be analyzed by the shortener
^KTIJ-26103 Fixed
To correctly provide the context for class header resolution, we save
the additional copy of the context right before `withRegularClass`
wrapper call in `LLFirBodyLazyResolver`. Otherwise we would have to
clear the existing context by hand, which is too cumbersome
(if at all possible)
^KTIJ-26024 Fixed
^KTIJ-24832 Fixed
Add a new method `isImplicitReferenceToCompanion` to determine
if the given reference is an implicit reference to a companion object.
The method is needed for the rename refactoring in IJ.
^KTIJ-25863
Otherwise, e.g., if a local type is within an anonymous object, full
class id will include that anonymous object too, resulting in invalid
type signature for PsiType.
^KT-59533 Fixed
FIR expressions rendered by FirRenderer don't look very nice in error
messages anyway, and additionally, they can become arbitrarily large,
so we shouldn't use them in messages.
#KT-59449 Fixed
There are too many possible error cases when code resolution cannot
properly resolve a call. Since in external mode `Logger.error` calls
lead to visible IDE errors, we want to avoid that
^KT-59093 Fixed
When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
`getReturnTypeForKtDeclaration` is called by UAST on probably compiled declarations.
In order to avoid redundant decompilation + building raw FIR + resolve,
let's delegate to deserialized FIR which is already prepared in stubs
Fixes KTIJ-24810
When `findSourceNonLocalFirDeclaration` is called on non-physical property accessor e.g.,
during completion, then traverse tree should allow drilling into FirProperty;
otherwise, no FIR would be found
In case of broken code e.g., duplicated classes provider would return first class,
though we definitely need some code insight in this case
at least to add navigation fixes, etc.
Similar to this, a file copy is created during completion,
where additional elements might appear and we need to search for them.
Added test cases for duplicated classes.
CompileTimeConstantProvider could receive a reference expression,
whose grandparent is KtTypeReference (seen that in UAST inspection).
FIR would not contain anything explicit for this reference,
FirResolvedTypeRef would be received as the nearest parent.
Of course, in this case, there could be no compile time constant anyway.
There are SOE exceptions caused by the fact that `getOrBuildFir` can
return a FIR declaration for the parent PSI. I wasn't able to reproduce
it locally, but this commit should prevent such problems by using
`getOrBuildFirSafe` with explicit type specification
This is needed because of mutable nature of receiver values: implicit
receiver values can be modified because of smartcasts, but in candidate
we need to store snapshot of receiver in the form it was at the beginning
of the resolution
^KT-58823 Fixed
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
aleksandrina-streltsova