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.
This is a step towards generating those classes. The code generator
won't care about default values in parameters,
and secondly, it will reorder some constructor parameters.
To keep source compatibility, new factory functions are created,
with the same signature as the constructor.
They will resist the change in order of constructor parameters.
Eliminating direct calls to constructors should also make further
refactorings a bit easier.
This change omits classes deriving from IrMemberAccessExpression,
as they are a bit more complicated
and will require separate effort.
#KT-65773 In Progress
Annotation arguments cannot contain declarations, so we can use empty
SymbolRemapper instead of DeepCopySymbolRemapper because the latter
introduces some overhead.
#KT-66281
Rename it to `deepCopyWithoutPatchingParents`, move to
`org.jetbrains.kotlin.ir.util`, make it inline+reified, and extract the
common implementation with `deepCopyWithSymbols` into `deepCopyImpl`.
At this point, `deepCopyWithVariables` is the same as
`deepCopyWithSymbols` except that the former doesn't call
`patchDeclarationParents`, which most likely produces incorrect IR in
some call sites.
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
It was only used to keep track of mappings from old type/value
parameters to new. We can do it manually instead of inheriting from
DeepCopySymbolRemapper, because the latter does more work than needed,
namely it creates 16 hash maps, and traverses the IR tree looking for
any other declarations.
#KT-66281
`hasEqualFqName` is called from `hasAnnotation`, which takes more than
1% of total backend time, so it's important to avoid doing extra work
here.
It seems to be a quirk of the JS IR backend specifically that
`JsExport.Ignore` has incorrect IR parent structure here; for all other
backends, checking FQ name by traversing IR parents should work fine.
#KT-66281
Those only implement base classes, their members are not supposed
to be referenced directly (those sometimes they are).
So unused code in there can be suspicious.
On the other hand, some generated builders are truly unused, so leave
the suppression for them.
There were several problems with it:
1) `isMoreSpecific` should return true if a == b. Otherwise
`isMoreSpecificThenAllOf` would never return true because it's always
invoked with a collection that contains the candidate. K1 behaves
similarly, `OverridingUtil.isMoreSpecific` returns true if a == b.
So in fact, "more" should be understood as "not less" here.
2) `transitivelyMostSpecificMember` in `selectMostSpecificMember` was
always equal to the first element, so `isMoreSpecific` was invoked
with incorrect arguments.
3) At the end of `selectMostSpecificMember`, we selected the first
candidate with the non-flexible return type, however only dynamic
type was considered. We need to check `isFlexible` via type system
instead.
#KT-66120 Fixed
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
It was the only IrElement with custom toString. And there is
a pending MR, which will override toString in IrElementBase, so this one
would be useless.
#KT-65773 In Progress
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.
Wojciech Litewka