If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
- revert some accidental changes in
`findSmallestElementOfTypeContainingSelection` function (see 48433bf9)
- simplify `dropFakeRootPrefixIfPresent` by using `tail`, add a new
test-case to check that it works
- simplify `findClassifierElementsToShorten` by not passing lambdas and
calling a common functions instead
This prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
Correctly handle `KtDotQualifedExpression`s with function calls as
selectors (like `foo.Bar()`). Without such handling, processing of
member invoke calls on objects was broken both
for reference shortener (causing KTIJ-26695)
and import optimizer (causing KTIJ-23407)
Also, to fix KTIJ-23407, do not ignore qualifiers with
`ImplicitInvokeCall` fake source
^KTIJ-26695 Fixed
^KTIJ-23407 Fixed
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
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
Dmitriy Novozhilov