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
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.
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
- Allows using those with the incoming IR implementation printer.
- Moves the logic to common tree generator, so other trees can specify
default values in base classes as well, if needed.
^KT-65773 In Progress
instead of inside implementation configuration.
Whether a field is a child element is a core concept of the tree,
not a matter of particular implementation class.
It is especially visible in IR tree, where the base classes implement the
acceptChildren method. It will also be more relevant in the future.
This also aligns the config style between IR and FIR tree generators.
^KT-65773 In Progress
The notion of IR element class being 'semantically leaf' is rather hacky.
Instead, now we only distinguish whether an element has its
implementation class, which is what this notion was actually trying to
represent.
^KT-65773 In Progress
When those classes become auto-generated, the order of constructor
parameters will differ.
This commit ensures they will still be resolved correctly.
^KT-65773 In Progress
to replace custom logic that would throw in case of IrUninitialized.
This is to remove custom logic from those classes,
so that source generator will be able to generate
them in a straight-forward way.
Otherwise, it would need to be thought about those special cases, which
is better to be avoided.
There are two consequences:
- The error message will be more generic, and won't contain reference
to the element.
- It becomes possible to reassign returnType
property with IrUninitializedType
and read it afterward.
^KT-65773 In Progress
This is to remove custom logic from those classes,
so that source generator will be able to generate
them in a straight-forward way.
Otherwise, it would need to be thought about those special cases, which
is better to be avoided.
It is also a small step for future work,
which likely involves making parent property nullable.
Unfortunately, this change causes a loss of some details from exception
messages.
^KT-65773 In Progress
Wojciech Litewka