1. the `primitive == object?.something` fusion should not apply to
`primitive.equals(object?.something)` because it can't;
2. coercions to Int are there for a reason - don't remove them;
3. better optimize `primitive == object?.something` -- the result
should be subject to if-null fusion, so it needs to have a specific
pattern that resembles safe calls.
#KT-47597 Fixed
^KT-47574 The fix done here supports only one level of substituting
underlying type-arguments.
HierarchicalTypeAliasCommonizationTest.`KT-47574 - test long typealias chain`
will assert proper behaviour for nested chains.
This drastically improves performance for now, since the previous
Adapter implementation was at least O(n^2). While the Adapter
implementation could have been reduced to O(n), the Signature of
StatelessCommonizer was misleading.
StatelessCommonizer will be introduced back later when other
Commonizer implementations are ready to be converted to a new
Signature.
After linking runtime, llvm-ir is modified to add checker function
call at all points where unknown function, which can possibly run long
is called. This function checks Native state is set, to avoid long locks
at gc.
Before we analyzed initializers of enum entry with scope for constructor
in implict type mode, so scope was untouchable. Now we analyze them
in body resolve phase, so previously we add value parameters to
constructors scope, which mess up scope of enum entry initializer
In some cases we check that some declaration (e.g. field) was
analyzed by checking type of it's body/initializer (is it implicit
or not), so if type of FirAnonymousObjectExpression is not implicit
we can skip resolve of anonymous object itself
`throw` is not needed in this case, because `error(...)` already
raises exception (so `throw` is unreachable). Also after previous
commit compiler reports `UNREACHABLE_CODE` warning on such `throw`
ObjectOutputStream.writeUTF(String) has an unsigned short limit on
String length. On Projects with deep nested modules subplugin
options could produce String over this limit.
^KT-45202 Fixed
By default, C functions compiled to bitcode by clang have the
nounwind attribute. If such functions throws an exception, the
behaviour is undefined.
Our interop machinery can process foreign exceptions on call sites
(terminate or wrap them in Kotlin exceptions). But if the interop
bridges have the nounwind attribute, LLVM optimizations (particularly
inlining) may lead to the situation when a foreign exception is ignored by
our foreign exception handler.
This patch fixes the issue by compiling bridges with -fexceptions flag.
This flag makes clang to not set the nounwind attribute, so exceptions
can be thrown through C frames.
Example of such class declaration would be `10 < class A` expression
The expression is uncompilable, but parsable. Unfortunately, the
FIR compiler does not save `class A` reference in it (because it
is not an expression, and only an expression can be a LHS or RHS of
binary expression `10 < ...`)
When we try to build light classes, we will try to find/build FIR
declaration for this class, but we won't be able to, and this will throw
an error
Adding this check should fix few
`FirKotlinHighlightingPassTestGenerated$Regression` tests
pyos