To avoid extra indirection via `IrElement$DefaultImpls` for elements
whose `transform` uses the default implementation. And also, to simplify
migration to auto-generated IR tree.
This makes it a bit more apparent, in profiler snapshots, where
parameter types are really needed. Also, hopefully it will improve
performance somewhat in cases where types are not needed.
For example, before this change about 1/3 of the time of
`DefaultArgumentStubGenerator.lower` on JVM was actually computing types
of parameters from dependencies, even though the actual types were not
needed, only the presence of defaultValue was used. This made it the
most time-consuming lowering phase on JVM.
After this change, default argument lowering is thus 50% faster, however
this time is in part distributed among other lowerings that visit the
whole override hierarchy for all methods and really need the types of
parameters, e.g. BridgeLowering, SyntheticAccessorLowering. So the
profiler snapshots are now more "honest".
Otherwise, when the function has inline class parameter, we get ICE.
We do not get the error without inline class parameter, since we
substitute type parameters in limited situations, which includes
inline class lowering.
#KT-51157 Fixed
Doing so speeds up psi2ir ~2 times, and thus improves total compiler
performance by about 6-8%.
Unless JVM IR is in the mode where linking via signatures is the only
way (-Xserialize-ir, -Xklib), signatures are actually not needed at all,
SymbolTable can use the frontend representation (descriptors for FE1.0,
and hopefully FIR elements for K2) as hash table keys. The only catch is
that since other backends still need to work with signatures, all the
common IR utilities, such as irTypePredicates.kt, need to work correctly
for IR elements both with signatures and without.
Also, introduce a fallback compiler flag -Xlink-via-signatures, in case
something goes wrong, to be able to troubleshoot and workaround any
issues.
#KT-48233
Make addArgument/addElement/putElement extension functions. This will
simplify transition to auto-generated IR.
Co-authored-by: mcpiroman <mcpiroman@gmail.com>
To simplify review of the upcoming IR tree generator.
Note that copyright is dated 2021, since that's in
license/COPYRIGHT_HEADER.txt which is used by generators.
This change only moves code around, no behavior is changed.
Specifically, ir.tree sources containing several declarations are split
into several files: one file per class, and one file for all extension
functions per package (IrDeclarations.kt, IrExpressions.kt,
IrVisitors.kt, IrConstructorCallTypeArguments.kt).
This is useful because after introducing IR tree generator, we can
easily see how generated sources are different from those which were
written manually, since Git will recognize file moves. Also, it will
keep Git history for sources which consisted of one big class + a couple
of extension functions (e.g. IrElementVisitorVoid.kt).
Alexander Udalov