StubBasedBuiltInsSymbolProvider does not work for now for common modules (KT-61757)
but compiler builtins provider `FirBuiltinSymbolProvider` works.
Also, stub-based symbol providers should not be used in standalone mode.
Testdata from standalone is updated because of the difference
in property accessors (KT-62449) between stub and compiler builtin symbol providers.
Additionally, this commit fixes the behavior of `KotlinStaticPsiDeclarationFromBinaryModuleProvider`.
As compiler builtin declarations have no PSI attached,
`KotlinStaticPsiDeclarationFromBinaryModuleProvider` is used to get PSI
from `DecompiledPsiDeclarationProvider.findPsi`.
`DecompiledPsiDeclarationProvider` is only used in UAST standalone mode.
If you want to shorten call like `foo.bar()` into `bar()`, then you
need your range to intersect with `bar` callee reference. Having only
`foo` in the range is not enough
Same goes for the type references - to shorten `foo.Bar` into `Bar`, you
need at least some intersection of your range with `Bar` reference
^KTIJ-27139 Fixed
^KTIJ-27015 Fixed
if property doesn't specify explicit type,
property's return type would be calculated by provided initializer
^KT-62588 fixed
Merge-request: KT-MR-12564
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
- In parallel to Kotlin declaration provider merging, we need a proper
merging strategy for package providers as well, because resolve
extensions may define additional package providers.
- Additionally, other non-scope-based package providers may be added in
the future, and the merger preserves these out of the box.
^KT-61791
Similar to K1 KDocLinkResolutionService used by Fe10KDocReference (to
support additional KDoc resolution), this commit adds K2 counterpart
AdditionalKDocResolutionProvider and uses it for KDocReferenceResolver.
^KT-62187
- Now that combined declared member scopes for Java classes contain
static callables, we don't need to search symbols in the static member
scope. (Note that the static member scope is too broad for this use
case, as it contains symbols from superclasses, but we only need to
look at declared members because the correct `containingClass` is
already chosen.)
^KT-61901
^KTIJ-25126
it's useful for IDE's features such as write UAST or refactorings
^KT-62302 fixed
Merge-request: KT-MR-12414
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
Before, `KtCodeFragment`/`FirCodeFragment` was analyzed as a part of
its context `KtModule`. This has the following complications:
- In non-source sessions, diagnostic reporting is globally disabled.
For code fragments, however, checking the code before passing it to
the backend is essential.
- Special treatment for call ambiguities in libraries
(`LLLibraryScopeAwareCallConflictResolverFactory`) becomes complicated
as the conflict resolver has to be applied to a library module.
- `KtCodeFragment`s usually have a shorter lifetime than their own
context. Caching may potentially be implemented differently for them.
^KT-61783 Fixed
Make `FirShorteningContext` correctly return symbols for type
parameters, so they are not ignored when scopes are inspected
Add additional type of `PartialOrderOfScope` - `TypeParameter`, because
otherwise it would have been classified as `Unclassified`, and that
breaks scopes comparison
Add missing type parameters to the scope of class header in
`ContextCollector`, add testdata for that
There is a bug in the compiler with type parameters leaking to nested
classes headers (KT-61959). After it's fixed, the testData with
incorrect expected shortenings/scopes should be adjusted and fixed too
^KTIJ-27050 Fixed
This should make reference shortener considerably faster, since it won't
need to perform redundant extra resolve of the file.
`ContextCollector` more accurately collects the scopes for the scripts,
so some script tests are also fixed.
It should fix the following bugs:
^KTIJ-26714 Fixed
^KTIJ-26727 Fixed
This is also an important part of fixing the following bugs:
- KTIJ-26715
- KTIJ-26734
But those bugs also rely on KT-61890, because completion uses scopes
and snows incorrect elements from them
- An enum entry is a variable which doesn't declare any additional
members. It must not be confused with its implementing anonymous
object initializer, which may declare additional members, but is an
implementation detail hidden outside the enum entry's initializer.
Hence, the enum entry variable should not have a (declared) member
scope.
- A following commit will add the ability to get the enum entry's
initializer, so that a member scope for this initializer can be
obtained (which might be relevant for local analysis).
^KT-61405 fixed
After the fix for the KT-60904 issue (c963eadb),
there are unnamed declarations created even for
the unused variables in destructuring declarations
Because of this, we can actually align testData
for K1 and K2. It seems like KT-59504 is no
longer relevant and can be marked as obsolete
because of the KT-60904 fix
^KTIJ-26959 Fixed
Ilya Kirillov