Completion in the IDE relies on correct scopes for KDoc positions.
So we add testData for `KtScopeProvider` and `ContextCollector`
to ensure that there are no regressions
- In addition to file declarations and class members, we also need to
commit pending diagnostics on declarations in scripts, to honor
suppressions before the diagnostics are committed indiscriminately.
^KT-62899
- `scriptUninitializedTopLevelProperty` is currently disabled in FIR
because it fails with a mismatch between diagnostics from the file and
the individual elements. It will be enabled in the next commit.
^KT-62899
- In KT-62899, diagnostics produced by file checkers weren't suppressed
because the top-level declarations on which the diagnostics are
reported were never visited by the same reporter.
`LLFirDiagnosticVisitor` skips nested declarations by design, as
diagnostics are collected for each structure element separately.
However, suppression takes effect when diagnostics are committed on
some element. If the element is not visited, suppression is skipped
and the diagnostic is committed at the end without a check by
`FileStructureElementDiagnosticsCollector.collectForStructureElement`.
- The fix ensures that diagnostics are committed on top-level
declarations, similar to how this was already done for class members.
^KT-62899 fixed
- `testConflictingOverloadsAtTopLevel` is currently disabled in FIR
because it fails with a mismatch between diagnostics from the file and
the individual elements. It will be enabled in the next commit.
^KT-62899
The existing reference shortener does not use import alias when it
shortens a symbol. Instead, it adds a new import directive for the
symbol that is already imported. This commit updates reference shortener
to let it reuse the existing import alias rather than adding a new one:
1. When shortening a symbol, check whether the symbol is already
imported.
2. If it is already imported by an import alias, keep the symbol
reference expression and the import alias as a string together in
`ShortenCommand`.
The actual PSI update (shortening) based on the ShortenCommand is done
by IntelliJ.
^KTIJ-27205
^KTIJ-27522 Fixed
It's the only reasonable behavior for this API in it's current shape
(when it returns a list of declarations)
It's a common mistake to take only Compatible from
expectActualMatchingMap. The problem will be gone after I fix KT-62590
Motivation to fix this bug, is because it will be easier for me to split
expect-actual matcher-checker-monster thing KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
`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
Kirill Rakhman