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
sebastian.sellmair