For implicit invoke operator calls, there are two instances of
`FirResolvedNamedReference`. One of them references `invoke` function
and cannot be used to analyze the property access, and the second one
has `source == null`. Luckily, the parent of the second reference is
`FirPropertyAccessExpression`, which has the correct source
^KT-60957 Fixed
As 'FirCodeFragments' are converted to IR independently of its context,
in some cases duplicate (and not quite correct) symbols for local
classes and functions are created.
Until properly fixed in fir2ir, here we replace such duplicates with
original symbols.
In the old JVM backend, local functions were compiled as JVM classes,
so there were an instance to pass around. Today, they are compiled to
static functions in the containing class/facade, and calls to them
compile natively.
To get to the proper qualified expression, we need to unwrap the outer
`FirVariableAssignment` if we deal with the property access inside of
assignment expressions
^KT-60954 Fixed
Inside `transformDeclarationContent` current tower data context is saved. Previously, stored context could be incomplete, because `dataFlowAnalyzer.enterFunction(function)` wasn't called in all cases.
^KTIJ-26419 Fixed
When optimizing imports, it does not make any sense to account for
type qualifiers which are not directly present in the code
ATM such implicit type references are present for every
callable declaration call
^KTIJ-24877 Fixed
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 allows us to properly complete array literals arguments of
annotation calls fixing several false-negative type mismatch errors
as well as enabling the inference of generic type arguments.
#KT-59581 Fixed
#KT-58883 Fixed
Even when the aliased import comes from the same package, it cannot be
removed, because it will break the code
Also, add more tests for the imports coming from the same package
^KTIJ-26276 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
Namely, in the previous commit we merged two
(LOW and HIGH priority default start import scopes) into the single one
For more explanations, please look at the previous commit
Calls to extension functions imported from objects have implicit
dispatch receivers, but those receivers are not present in the code
and should not be analyzed by the shortener
^KTIJ-26103 Fixed
To correctly provide the context for class header resolution, we save
the additional copy of the context right before `withRegularClass`
wrapper call in `LLFirBodyLazyResolver`. Otherwise we would have to
clear the existing context by hand, which is too cumbersome
(if at all possible)
^KTIJ-26024 Fixed
^KTIJ-24832 Fixed
Roman Golyshev