In this way, only `LLFirLazyResolver` will be responsible for running
and checking the resolution result.
Also, this commit replaces redundant `checkIsResolved` for
`LLFirResolveTarget` with cheaper `checkIsResolved` for declarations.
Also, this commit adds the missing global lock for `IMPORTS` phase.
This commit doesn't change any logic for the case with disabled lock
(the default case), only updates the case with enabled lock.
^KT-66306 Fixed
During this phase, the compiler will evaluate initializers of
const properties and defaults of annotation's constructor.
Evaluation results will be stored in corresponding attributes.
#KT-64151
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
This extension point allows changing the return type of call
from a declared type to its subtype.
With an idea that such a plugin needs the ability to
control available (extension) properties for this type.
A set of properties should be decided based on the resolved function,
provided arguments, types, and resolved lambdas.
It is not a goal to enable plugins to affect resolution in any way.
Types are not intended to have any structured capabilities
In other words.
The goal was to come up with a way to enable a limited form
of an "extensible records" mechanism through plugins.
- It should give enough value for a practical use.
(more info in the ticket).
- It should have minimal effect on the compilation process
This appears to be an extension point that solves this problem.
^KT-65859 Fixed
This element has been introduced to simplify resolution logic in LL FIR,
but now this element is redundant and only complicates the code as after
KT-56683 `FirFile` has real phases
^KT-65876 Fixed
- This was missed during the refactoring made by 46d5d512, which removed
`registerDefaultComponents` calls from platform-specific session
factories (including binary library session creation).
- Unfortunately, this doesn't fix KT-65563, which has also appeared
recently and I thought might be related.
^KT-66173 fixed
The commit "K2 scripting: treat default import similarly to K1"
introduced the new extension that provides default imports for scripts,
instead of the previous approach of explicit `FirImport` elements
creation. But registering it for the IDE case was forgotten. This
commit adds missing registration.
#KTIJ-28960 fixed
When we have parameters of annotation like
```
// FILE: Anno.kt
package p3
@Target(AnnotationTarget.FUNCTION)
annotation class Anno(vararg val x: String)
// FILE: main.kt
import p3.Anno
@Anno("A", "B")
fun foo(): Int = 10
```
the K2 CodeGen causes an exception reporting the unresolved type
reference. A lazy resolution call fixes the issue.
In addition, FIR for the value parameter to IR conversion fails because
`Fir2IrLazyProperty` for the value parameter tries to resolve the
initializer before creating the `IrParameterSymbol`. When it checks the
`localStorage`, it reports an error for the missing `IrParameterSymbol`.
This commit adds `IrParameterSymbol` before resolving the initializer.
^KT-65099 Fixed
- This commit moves all session invalidation tests from the IDE which
are non-cyclic to the Analysis API. Cyclic session invalidation tests
cannot be moved because the Kotlin test infrastructure doesn't support
cyclic module dependencies.
- In fact, these new tests cover more cases, because the IDE tests only
covered global module state and module out-of-block modification
events. Crucially, global source modification events are now
supported, which require libraries to be left alone.
- Module out-of-block modification for libraries is technically
undefined, but the test still checks this behavior. The current
session invalidation implementation behaves the same for any kind of
module-level modification event, so it is possible to publish a module
OOBM event for libraries. If this changes in the future, we can
disable those tests. But for now, it's good that these tests run,
because they will alert us to (accidental) changes to this behavior.
^KT-56288 fixed
^KT-65265 fixed
- Rewrite `TestModule.publishModificationEventByDirective`: we can get
the `KtModule` to publish an event for via the test module. The
directive can now be made optional, which is necessary when we want to
specify it in potentially multiple modules.
- Introduce the `WILDCARD_MODIFICATION_EVENT` directive, which allows
specifying THAT some modification event should be raised for a module,
but not WHICH one. This allows generating multiple tests which raise
different modification events over the same test data.
- Add various convenience functions for publishing wildcard modification
events. `publishWildcardModificationEventsByDirective` for the test
module structure is quite opinionated, but takes a lot of work from
test implementations.
- Because `ModificationEventDirectives` are part of the analysis test
framework, we register them as a general Analysis API test directive.
^KT-56288
Instead of always looking up smart casts on `lastNode` and separately
tracking the receiver state, simply track which flow the smart casts
belong to right now. This tracked flow is auto-advanced when new
`lastNode`s are created, but can be manually rolled back for things like
KT-63709.
- Unified and optimized visitor instead of transformer with many
redundant operations.
- `LLFirAnnotationArgumentsTargetResolver` now has the correct state
keeper for nested declarations – e.g., property accessors or value
parameters.
- `FirAllLazyAnnotationCalculatorVisitor` in tests now almost the same
as in the production as now it uses the same visitor without recursive
visiting
^KT-63606 Fixed
^KT-64000 Fixed
^KT-64579 Fixed
We don't have to resolve `FirFileAnnotationsContainer` before each
declaration.
This became possible after KT-65345 as now `FirDesignation` has `FirFile`
in its path so, `PersistenceContextCollector#collectContext` resolves
it as well as we don't have problems with unresolved annotations
during diagnostics processing
^KT-65876
Dmitrii Gridin