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
Invert the logic of IR/FIR2IR-based generators: change the CLI argument
to -Xuse-fir-fake-override-builder, test directive to
USE_FIR_BASED_FAKE_OVERRIDE_GENERATOR, etc.
The changes in test data caused by using IR fake override builder by
default are in the subsequent commit.
#KT-61514
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.
- Perform all calls to xcrun in XcodeValueSource.
- Use the fully computed Xcode instance as the current Xcode instance.
- Hide all of this inside a Gradle plugin and apply it to kotlin-native
project.
- 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
Ilya Chernikov