The idea of optimization is simple – delay in-block modification
until the end of a write action.
Q: Why the end of write action?
A: We have to publish the result of modification somewhere during
write action to be sure that the next read action will see the
updated result. We can't publish the result somewhere later
because we can't guarantee that the modification will be visible
to all customers.
In the case of out-of-block modification, we still have to publish
the result immediately because it is hard to evaluate the consequences
of the opposite decision yet.
If an out-of-block modification happens, we can drop all previous
in-block modifications from the queue because they don't make sense
due to invalidation of the entire KtModule.
A corner case is the analysis under write action. The delay means that
there is no longer any guarantee that all PSI changes will be reflected
into FIR tree immediately. So now we can guaranty only that at
the start of `analyze` block you will have the up-to-date FIR tree.
^KT-60611 Fixed
FirDeclarationsResolveTransformer.transformSimpleFunction() performs
proper local function analysis only if the parent is properly set.
^KTIJ-26608 Fixed
Otherwise, such types are treated as resolved, but anyway
requires transformation on type phase.
Also, this commit drops the redundant duplicated transformation of
typeReference from primary constructor property generator
^KT-61422
- Previously, `KtFirAnonymousObjectSymbol` was a
`KtEnumEntryInitializerSymbol`, which carried the risk that an
anonymous object unrelated to enum entries might be used as an enum
entry initializer. This commit introduces a specific symbol for FIR
enum entry initializers.
- As a nice side effect, anonymous object symbol creation is simplified
and `KtFirEnumEntryInitializerSymbolPointer` can restore the symbol
via `KtFirEnumEntrySymbol.enumEntryInitializer`.
^KT-61425
- 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
- An enum entry is a variable which doesn't declare any additional
members. It must not be confused with its implementing anonymous
object initializer, which may declare additional members, but is an
implementation detail hidden outside the enum entry's initializer.
Hence, the enum entry variable should not have a (declared) member
scope.
- A following commit will add the ability to get the enum entry's
initializer, so that a member scope for this initializer can be
obtained (which might be relevant for local analysis).
^KT-61405 fixed
- The implementations of some FIR scopes contain a significant amount of
delegation to some original scope. This pollutes the implementation of
such scopes and makes them harder to read.
`FirDelegatingContainingNamesAwareScope` and `FirDelegatingTypeScope`
can be used as base classes which delegate by default.
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
Note that 3 tests are still muted, but for another reason: for FIR
versions of the tests, we need to compile the "pre-release library" with
the next language version which is 2.1. But since currently
LanguageVersion.LATEST_STABLE is 1.9, the compiler refuses to read
metadata of version 2.1, regardless of its own language version. Which
is correct, but it leads to irrelevant errors in the test output -- the
ones about the incompatible metadata version, NOT about the
prereleaseness.
These 3 tests can be unmuted once the default language version is
switched to 2.0.
#KT-60780 Fixed
^KT-61573 Fixed
Review: https://jetbrains.team/p/kt/reviews/11969/timeline
Tests:
- MultiPlatformIntegrationTestGenerated
- CliTestGenerated
- MultiPlatformIntegrationTestGenerated
- DiagnosticTestGenerated.Multiplatform
- FirLightTreeOldFrontendDiagnosticsTestGenerated
Also add -Xexpect-actual-classes flag to all necessary ./libraries/* modules
Otherwise compilation of those modules failes because of `-Werror`
`KtReference` might be resolved from anywhere, even
from the write action - the call site might not know
anything about Kotlin, and might not be able to
somehow prevent the `inaccessible analysis session`
exception from being thrown. That's why we
have to be permissive here.
^KTIJ-26867 Fixed
After the KT-61568 has been fixed, `isInBestCandidates`
correctly works in more cases, and can be more
reliably used in `KtFirReferenceShortener`
^KTIJ-26808 Fixed
^KTIJ-26840 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
In complex projects, there might be several library copies (with the
same or different versions). As there is no way to build a reliable
dependency graph between libraries, a project library depends on all
other libraries. As a result, there might be several declarations in the
classpath with the same name and signature.
Normally, K2 issues a 'resolution ambiguity' error on calls to such
libraries. It is acceptable for resolution, as resolution errors are
never shown in the library code. However, the backend, to which
'evaluate expression' needs to pass FIR afterwards, is not designed for
compiling ambiguous (and non-completed) calls.
Lowering asks whether to generate getter/setter call only when it should
be present. It means the code define explicit getter or setter.
And it seems correct to use it instead of trying direct field access.
The same way as `FirClassUseSiteMemberScope` is present
when there is an implicit receiver with a pure Kotlin type,
`JavaClassMembersEnhancementScope` is present when
the receiver's type comes from Java sources
^KTIJ-26785 Fixed
We shouldn't process other elements (like parameters/receivers) because
we can't modify them anyway. This will help to avoid exceptions like
```
Attempt to load text for binary file which doesn't have a decompiler plugged in
```
in tests
^KT-61431
Dmitrii Gridin