Result of calling `ExpressionCodegen.gen` was used only in two call
sites in the inliner. In all other call sites, we were doing unnecessary
work (and sometimes were even failing) by trying to construct a
KotlinType instance out from an IrType.
Note that even though the code from KT-50617 no longer fails to compile,
the underlying problem is still not solved, since the IrType for foo's
dispatch receiver is constructed incorrectly. The reason is that
SymbolTable links everything by IdSignature, which is identical for
classes with the same FQ name.
#KT-50617 Fixed
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).
Previously IC state was stored in System properties. As result parallel
compilation might cause incorrect state of IC, what led to corruption
of kotlin_module files. Now IC state is stored via CompilerArguments
and CompilerConfiguration
#KT-46038 Fixed
The temporary solution for KT-50546.
The complete solution requires the understanding,
whether a cross-module symbol redeclaration is a valid case or not.
If the case is valid, the linker symbol table logic must be reworked.
There are two possible scenarios, when fun interface method with inline
class parameter can be compiled.
First is when we compile fun interface itself before SAM adapter. In
that case, fun interface is lowered before we lower SAM adapter. Thus,
its method is mangled and mangling in the second time is an error.
Second is when we compile SAM adapter before the fun interface. In that
case, fun interface is not lowered, and we have to mangle the method.
The only way to distinguish there two cases I can think of is to check
whether the overridden method is already mangled, in other words, check,
whether the overridden method's suffix is doubled.
#KT-48499: Fixed
Xin Wang