Use existing stub-based JVM library symbol provider for .knm and
.kotlin_metadata files. The only real difference is the scope filtering
by file types
KT-58769
We cannot always return null, because in such case some expressions
would become not fully explorable from the types perspective (see
the documentation on the `getCorrespondingTypeIfPossible`)
`FirNamedReference` might appear when resolving method references (like
`foo::bar`), but also when IJ Platform tries to resolve other parts of
the Kotlin PSI, notably a `KtNameReferenceExpression` in a
function call (`bar` in `foo.bar(baz)` expression).
N.B. FE10 implementation does not support returning `null` as a type -
currently it always returns `Unit` type in case it cannot figure out
the actual type. This issue should probably be tackled together with
KT-60166, so that both implementations are more or less aligned
^KT-60341 Fixed
^KT-59077 Fixed
^KTIJ-25745 Fixed
This provider is responsible for answering queries related to resolve
extensions. At the moment, this includes retrieving a KtScope with all REx
top-level declarations (moved from KtSymbolFromResolveExtensionProvider), and
retrieving information necessary to supply a GeneratedSourcesFilter for REx
generated code. Future REx-related functions can be added to this interface.
^KT-59329
- Add package and constructor listings
- Add single-scope renderForTests() implementation, including a lambda
to provide additional information about each symbol
- Remove special handling for empty scopes (interfered with single-scope
rendering)
^KT-59329
Tests can now specify the code generated by a resolve extension from
within the test's testdata. Module-level directives control whether
resolve extensions are enabled for that module, as well as package names
and source shadowing regexes. File-level directives allow a `// FILE:`
block within the testdata to be converted into a KtResolveExtensionFile
and removed from the module as a whole. (This requires a new
`ModuleStructureTransformer`, because we need to be able to entirely
remove the files in question.)
Any test can add support for these directives by calling
`KtResolveExtensionTestSupport.configure` from within their
`configureTest` stanza. This allows this functionality to be used in
conjuction with any test base class.
^KT-59329
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
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.
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59243 Fixed
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59240 Fixed
To create a smart psi type pointer, IJ Platform uses resolve.
We cannot use resolve from JavaSymbolProvider, as it may lead to resolve contract violation.
^KT-59133 fixed
KtResolveExtensions are designed to handle IDE analysis use cases where
source might not be available at analysis time, because that source is
generated by an external source generator, such as an annotation
processor or resource compiler. The sources generated by those external
generators can appear in the analysis scope, and cause issues with
source clash - resolution may find the virtual source from the
KtResolveExtension, the on-disk generated source from the external
generator, or both. This can cause issues, because that on-disk
generated source may be stale, and may not have symbols that will exist
the next time the generator is run (or, conversely, may have symbols
that will disappear on the next build).
To solve this, add a `getShadowedScope(): GlobalSearchScope` to
`KtResolveExtension`. Any files in the module that are included in that
scope will be hidden from resolution, allowing the resolve extension to
cleanly replace those files.
^KT-58834 fixed
- To test the reference resolution of declarations provided through
resolve extensions of module dependencies, we need support for
multimodule resolve extension tests.
- A proper merging strategy for declaration providers is required for
cases where the main declaration provider created by
`createDeclarationProvider` can't provide all declarations that the
original declaration providers can provide. Then, only a sublist of
the declaration providers should be merged, while keeping the
unmergeable declaration providers intact.
^KT-58580 fixed
When we create `SmartTypePointer` directly inside `JavaSymbolProvider`,
the Java resolution is called which is forbidden inside the
`JavaSymbolProvider`.
Instead, the lazy `JavaElementTypeSource` for JavaType is created,
which creates a `SmartTypePointer` outside `JavaSymbolProvider`.
^KT-58194
This is needed for the cases when a candidate name set is known
to avoid retrieving a set with all possible names when processing the scope.
Similar to KtScope.
^KT-58653
This is needed for the cases when a candidate name set is known
to avoid retrieving a set with all possible names when processing the scope.
^KT-58653 fixed
this gives the following benefits:
1. no protobuf in memory, all data is already present in stubs
2. given that symbol provider for libraries is already stub based,
we can get rid of complicated code to find source psi by deserialized fir
3. it's also possible to reduce number of index access,
when fir is requested for given ktElement
Pavel Kirpichenkov