It is now unneeded, and future needs should be possible to
be resolved otherwise.
Removing it will simplify further changes to tree generator,
especially for IR.
IrConstructorCall is already used to represent both regular constructor
call and annotations.
Implementing AnnotationMarker avoids 'casting' it to this type later on
in IrTypeSystemContext, which was done with
a new IrElement implementation. We'd like to
avoid such implementations, e.g. as so to make the IR hierarchy sealed.
#KT-65773 In Progress
in effort to simplify implementation classes when possible.
Those two properties always point to IrFactoryImpl, so it may as well
be used directly.
#KT-65773 In Progress
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
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
Those fields were effectively marked as child elements after refactor.
However, because of the current (to possibly be changed) configuration,
the generator did not write accept methods for them.
Wojciech Litewka