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
analogous to printFunctionDeclaration.
This decouples the printing logic from handling IR elements' fields,
and makes it easier to directly print arbitrary fields.
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
This commit removes the default parameter in constructor,
as well as custom logic in this class, which would
make it harder for its subsequent auto-generation.
^KT-65773 In Progress
The default value of those properties is a detail that should be handled
by implementation or builder layer.
This change will also simplify auto-generating and reasoning about
generated implementation classes, and allow for potential further
enhancements like intercepting all mutations.
^KT-65773 In Progress
It is required, so that IR tree generator will properly handle
the `annotations` property in subsequent commits,
e.g., to include them in implementation classes.
All subclasses of IrMutableAnnotationContainer
do already derive from IrElement.
^KT-65773 In Progress
If there is an expression receiver, we should process constructors only
of inner classes. Constructors of nested classes can be called only
on classifier
^KT-65333 Fixed
Wojciech Litewka