Do not generate linenumber for the start of the finally block, because
that is usually where the only word 'finally' is located. Instead,
generate linenumber for the first expression inside the finally block.
Not generating this linenumber fixes an issue in code coverage tools
which would consider such finally uncovered. Although this might be
technically considered as designed, it makes more sense to NOT detect it
as uncovered because semantics of the finally block shouldn't really
differ whether it's executed normally or because an exception happened.
It's also beneficial for the tool support to behave like javac, which
doesn't generate the linenumber either.
#KT-50973 Fixed
in case of deep upper bound hierarchy of generic underlying value,
especially when upper bound is another inline class with generic
underlying value.
#KT-32162
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
Static inline class replacements are possible only in inline classes.
Iterating over class declarations here took ~0.5% of backend time on
average projects, and up to 4% of total compilation time on degenerate
projects such as the one in KT-20055.
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
Ilya Chernikov