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>
- An inner class `Inner` in a class `Outer` is accessible as
`Outer().Inner()` and should thus be part of the non-static declared
member scope.
- Related issue containing a discussion about inner classes in use-site
scopes: KT-62023.
^KT-61800
- Member scopes already don't contain static callables, only their
static member scope counterparts. However, declared member scopes
contained both non-static and static callables, which was confusing to
users. See for example KT-61255.
- Now declared member scopes only contain non-static callables and
static declared member scopes only contain static callables.
- In `KtFirScopeProvider`, the new implementation is different for
Kotlin and Java classes, because the standard declared member scope
doesn't work for Java. Instead, we have to get the Java *enhancement*
scopes from `JavaScopeProvider`. Unfortunately, `JavaScopeProvider`
doesn't have a direct enhancement declared member scope. This results
in a somewhat complex scope structure with the declared members filter
scope around the use-site/static Java enhancement scope, but since the
declared members filtering scope properly reduces the set of callable
names and scopes in general are cached, this shouldn't be an issue.
- `getCombinedDeclaredMemberScope` is introduced as a separate public
function because for Kotlin scopes, we don't actually have to create a
combined scope, as the non-static and static scopes are just filters
around a combined declared member scope provided by the compiler. It's
also important to have a convenient function to get the combined
declared member scope, because some usages explicitly want access to
all declared members (such as symbol light classes).
- This commit also fixes KT-61901, because
`getFirJavaDeclaredMemberScope` now provides a proper static scope for
Java classes, which will be accessible via the combined declared
member scope as well.
^KT-61800 fixed
^KT-61901 fixed
^KT-61255 fixed
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>
FIR implementation already does not have this check in
`createContextDependentCopy`, because it's called not
inside `analyze` call, but before it (see
`analyzeInDependedAnalysisSession`)
^KT-62139 Fixed
- An enum entry's body is an initializer with members only accessible
within that body. Because users of the Analysis API might want to
analyze the members of the enum entry initializer, we expose this
initializer via `KtEnumEntrySymbol`. The initializer only exists if
the enum entry has a body.
- We already have some usages of the initializer inside symbol light
classes, which generate a light class for each enum entry, which
includes the enum entry's hidden members.
- To hide the implementation detail that initializers are anonymous
objects, `KtEnumEntryInitializerSymbol` is simply a
`KtSymbolWithMembers`.
- The advantage of making it a `KtSymbolWithMembers`, instead of
providing a custom way to get a member scope, is that we can pass
around the initializer easily, e.g. in `KtEnumEntrySymbolRenderer`.
- We implement `KtEnumEntryInitializerSymbol` directly as a
`KtFirAnonymousObjectSymbol` without a wrapper. This has a few
advantages:
1. We can directly benefit from the anonymous object symbol being a
`KtSymbolWithMembers`, so we don't have to handle enum entry
initializers specially in e.g. `KtFirScopeProvider`.
2. We don't have to implement a new symbol restoration mechanism for
the initializer.
3. This implementation matches the actual FIR tree structure (with a
simplification that the connecting anonymous object expression
between the enum entry and the initializing anonymous object is
omitted).
^KT-61425 fixed
After the fix for the KT-60904 issue (c963eadb),
there are unnamed declarations created even for
the unused variables in destructuring declarations
Because of this, we can actually align testData
for K1 and K2. It seems like KT-59504 is no
longer relevant and can be marked as obsolete
because of the KT-60904 fix
^KTIJ-26959 Fixed
`firResolveSession.getTowerContextProvider` should already
contain all the relevant scopes, including default and
importing scopes for the file
Because of this, import and default scopes had presence over the
more local scopes, and the resolve was performed incorrecty - top level
candidates were given higher priority
^KT-61568 Fixed
^KTIJ-26824 Fixed
One of the compiler lowerings, namely `PropertyReferenceLowering`,
optimizes usages of property references in some cases,
and if a containing delegated property accessor is inline,
it might need this accessor's bytecode.
If an accessor function is defined in a different module,
IDE tries to acquire its bytecode via the index, however,
the index doesn't cover classfiles from compiler output,
and that leads to errors like KTIJ-26706 and IDEA-320283.
One of the ways to ensure that the bytecode exists is to include files
that contain inline accessors in the compilation process. For example,
if file f1.kt from the analysis result contains property `val p by D()`,
and `D.getValue` is an inline function defined in file f2.kt,
then f2.kt must be present in the analysis result.
If f2.kt contains another property `val q by E()`,
and `E.getValue` is an inline function defined in f3.kt,
then f3.kt must be present in the analysis result. And so on.
Fixes KTIJ-26706, IDEA-320283
Merge-request: KT-MR-11793
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
Otherwise, it will throw exception like:
```
IllegalStateException: No 'FirJvmTypeMapper'
```
Anyway, PsiType is JVM conception, so it is not supposed to be used
outside the JVM platform
^KT-60318
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
This reverts commit 529a1dd720.
This commit was needed to workaround broken incremental compilation in
JPS in Kotlin plugin. The incremental compilation bug is reported
KT-60759
As promised in 529a1dd720, after a few
days in `master` I revert it
Review: https://jetbrains.team/p/kt/reviews/11724/timeline
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
Also adds rendering of @Metadata annotations in Kapt3 and Kapt4 tests
(currently disabled for a few tests).
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
This is needed to workaround broken incremental compilation in JPS in
Kotlin plugin. The incremental compilation bug is reported KT-60759
In Kotlin plugin I created the same commit which changes the name of the
function on the call-site.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
After a few days in master branch, I will revert this commit
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
The API replaces 'KotlinCompilerIde' in the IntelliJ IDEA plugin.
Code moved to Analysis API as its K2 implementation severely depends on
the internal compiler API (FIR).
The API is going to be used in the JVM debugger evaluator, and in
the Bytecode Tool Window.
In this commit, only ordinary Kotlin are supported.
In later commits, there will be also support for 'KtCodeFragment' files,
as well as some test coverage.
Dmitrii Gridin