- 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
Checker for conflicting declarations will now check for the following
scenarios too
- two expect declarations in different modules
- actual and non-expect declarations in different modules
^KT-63826 Fixed
Code fragment is a class that extends from Any, so technically it can
have fake overrides for equals/hashCode/toString. However, K1 does not
build them, and it's already checked in IR text tests in
`analysis/analysis-api/testData/components/compilerFacility/compilation/codeFragments`,
so don't build them in K2 as well. Also, the code in
`KtFirCompilerFacility.createJvmIrCodegenFactory` looks for a single
function defined in the code fragment.
This change fixes FIR tests with JVM IR serialization enabled, some of
which start to fail after enabling IR fake override builder mode by
default.
In this case, even accessing the function body with `IrFunction.body`
does not work in some cases because it tries to load IR and ends up with
unbound symbols for some reason (most likely related to KT-63509). So we
avoid accessing the body by copying the `IrFunction.acceptChildren`
implementation and removing the `body.accept` call.
Using deep-copy to create a fake override is questionable here, but it
will need to be refactored separately.
IR expressions are left out for now, because unlike declarations,
which are mostly created via IrFactory, expressions' constructors are
widely used, and it's hard to replicate the exact signatures of those
constructors with the tree generator.
Therefore, some other approach is expected to be taken when generating
them in the future.
^KT-65773 In Progress
Dmitrii Gridin