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>
We should process generated property as a part of the primary constructor.
This was already implemented in 8387ea8a, but some parts were missed.
ClassDiagnosticRetriever:
* dropped relation to properties generated from constructor parameters
as they should belong to the primary constructor only
* accurate logic to fully visit an implicit primary constructor to be
able to process nested declarations (e.g., inside a super type call)
SingleNonLocalDeclarationDiagnosticRetriever:
* add relation to generated properties as now they fully belong to
the constructor
FileElementFactory:
* dropped explicit resolution of generated properties from a constructor
* added explicit resolution of generated enum members for consistency.
Effectively, this is not required because we don't have compiler
checkers for such generated enum member declarations
ClassDeclarationStructureElement:
* do not collect mapping for generated properties from constructor
* explicitly declare that we should process only ClassDelegationField
^KT-62437 Fixed
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
- Java combined declared member scopes are implemented as a composition
of the non-static and static scope, so we have to exclude inner
classes from the non-static scope to avoid duplicates.
- This is not an issue for Kotlin combined declared member scopes,
because the combined scope is already the base scope.
^KT-61800
- An inner class `Inner` in a class `Outer` is accessible as
`Outer().Inner()` and should thus be part of the non-static declared
member scope.
- Related issue containing a discussion about inner classes in use-site
scopes: KT-62023.
^KT-61800
- The semantics of a non-static declared member scope should be as
follows: For a variable `c: C` of class type `C`, the declared member
scope should contain all members `x` accessible as `c.x` (visibility
notwithstanding) which are *also* explicitly declared in `C`.
- Classifiers are not accessible as properties of a variable `c`, only
as static members of the class `C` itself, so non-static declared
member scopes should not contain any classifiers.
^KT-61800
- The function is mostly for convenience, but scope providers will be
able to optimize this scope if needed (similar to how combined
declared member scopes are already optimized).
- `getCombinedMemberScope` will be used by `KDocReferenceResolver`.
^KT-61900
- 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
- Now that non-static declared member scopes don't contain static
callables anymore, we have to update some usages in the Analysis API.
- In symbol light classes, many usages of `getDeclaredMemberScope` can
be kept as-is because Kotlin classes/objects generally cannot declare
static callables (and we do not need to create symbol light classes
for Java classes). The only exception are enum classes, which
implicitly declare some static callables.
^KT-61800
- Member scopes already don't contain static callables, only their
static member scope counterparts. However, declared member scopes
contained both non-static and static callables, which was confusing to
users. See for example KT-61255.
- Now declared member scopes only contain non-static callables and
static declared member scopes only contain static callables.
- In `KtFirScopeProvider`, the new implementation is different for
Kotlin and Java classes, because the standard declared member scope
doesn't work for Java. Instead, we have to get the Java *enhancement*
scopes from `JavaScopeProvider`. Unfortunately, `JavaScopeProvider`
doesn't have a direct enhancement declared member scope. This results
in a somewhat complex scope structure with the declared members filter
scope around the use-site/static Java enhancement scope, but since the
declared members filtering scope properly reduces the set of callable
names and scopes in general are cached, this shouldn't be an issue.
- `getCombinedDeclaredMemberScope` is introduced as a separate public
function because for Kotlin scopes, we don't actually have to create a
combined scope, as the non-static and static scopes are just filters
around a combined declared member scope provided by the compiler. It's
also important to have a convenient function to get the combined
declared member scope, because some usages explicitly want access to
all declared members (such as symbol light classes).
- This commit also fixes KT-61901, because
`getFirJavaDeclaredMemberScope` now provides a proper static scope for
Java classes, which will be accessible via the combined declared
member scope as well.
^KT-61800 fixed
^KT-61901 fixed
^KT-61255 fixed
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
This is needed because in order to figure out which declarations are
visible from anonymous objects in terms of overridability (see
`FirVisibilityChecker.isVisibleForOverriding`), we need to get the
package name of that anonymous object, because there's package-private
visibility on JVM.
#KT-62017 Fixed
Backend requires annotation constructors to be fully resolved for the
'IrConst' default value lowering. However, in the IDE there is usually
no need in complete annotation class resolution.
^KTIJ-27061 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
The idea of optimization is simple – delay in-block modification
until the end of a write action.
Q: Why the end of write action?
A: We have to publish the result of modification somewhere during
write action to be sure that the next read action will see the
updated result. We can't publish the result somewhere later
because we can't guarantee that the modification will be visible
to all customers.
In the case of out-of-block modification, we still have to publish
the result immediately because it is hard to evaluate the consequences
of the opposite decision yet.
If an out-of-block modification happens, we can drop all previous
in-block modifications from the queue because they don't make sense
due to invalidation of the entire KtModule.
A corner case is the analysis under write action. The delay means that
there is no longer any guarantee that all PSI changes will be reflected
into FIR tree immediately. So now we can guaranty only that at
the start of `analyze` block you will have the up-to-date FIR tree.
^KT-60611 Fixed
FirDeclarationsResolveTransformer.transformSimpleFunction() performs
proper local function analysis only if the parent is properly set.
^KTIJ-26608 Fixed
Ilya Kirillov