`KtImportOptimizerResult.unusedImports` should be removed soon, and
part of the testdata for the import optimizer service should go
to `intellij` repository
Implicit receivers generally do not affect the resolution of types.
However, they generate scopes which might contain undesirable
classifiers, which can confuse reference shortener.
Dropping all the implicit receivers when dealing with type references
allows completely avoid such undesirable scopes instead of filtering
them by `instanceof` checks.
Also, temporary move `hasTypeParameterFromParent` check higher to the
`findClassifierElementsToShorten`, because ATM we don't know how to
properly decide whether to shorten the fully-qualified inner types
with implicit parameters or not (see KTIJ-26072).
^KTIJ-26057 Fixed
- 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
`implicitScope` can be `null`
in case when the implicit receiver resides in a user-defined `kotlin.*`
package, but the user have not yet allowed this with compiler argument
directive.
In this case,
we don't want the IDE to crush and show exceptions - the `kotlin`
package would be highlighted by the compiler diagnostics and other
resolve problems, and that would be enough
^KT-62071 Fixed
The commit (7db2fc522e) with changing behavior of builtin symbol provider
is in a conflict with a commit (72de86a8ba) where new tests were added.
The difference should be fixed as a part of KT-62651
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
- 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
- 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
- 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
Roman Golyshev