- 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
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
In Native and JS, there is a special logic where the compiler saves
a copy of inlined function (see `InlineFunctionsSupport`). This copy
is used in the IR inliner. Because of that, we can't really compare
inlined function with other functions directly. We need to
get `originalFunction` first and save it.
This is an addition to d4278250e6. Apparently we still need to produce
a new fake override for each inherited static member, because otherwise
we would try to determine the most specific return type, maximum
visibility, etc, all of which makes no sense for static members.
#KT-66152 Fixed
The problem was that in K2 for some top-level script declarations we
need to add a dispatch receiver parameter (because frontend do not
assign any, but representing script as a class requires it to be the
script class) and at the same time, calls to these declarations rely on
properly set dispatch receiver parameter.
The simplest solution found is to have an additional traversal on the
relevan top-level declarations and assigning the dispatch receiver,
before running the main transformation.
#KT-64502 fixed
When using DeepCopyIrTreeWithSymbols as class transformer to transform
the IrClass, the source element of IrClass was set to
SourceElement.NO_SOURCE after the transform.
^KT-65343 Fixed
`originalCallee` is supposed to be the owner of the original call.
It can be a fake override, and in the inliner we are using actual
function with body. Apparently we can just stick with the resolved
function.
#KT-64807
The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
It was a workaround for case, where expect class don't have
override of abstract function. We don't allow it anymore,
so it can be dropped to make correct modality comparation.
^KT-65971
This fixes some crashes on red code in diagnostic tests.
Also can be useful in the future, when we would allow things like
enum.name in annotation arguments.
^KT-65971
Wojciech Litewka