The right way is to add something like KonanTarget.MSVC_X64, but doing
so requires changes throughout whole compiler. It would be especially
painful in HostManager, where we would need to deprecate
KonanTarget.MINGW_X64 as host. Instead we "hack" ClangArgs to compile
for x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in JNI case.
CI may contain custom MSVC and Windows Kit installation path, so we
should support it. Things might break when machine has several MSVC
installed (at custom and default path), but it sounds more like
incorrect environment setup problem than ours.
Since LLVM for Windows is now native instead on MinGW, we have to
compile code in a different environment in case of JNI. This commits
just separates ClangArgs into two subclasses without actual behavior
changes.
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
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.
48a684c0 added custom LLVM diagnostic handler, using JvmCallbacks machinery,
thus triggered a bug in the latter: callbacks are cached and outlive the compilation session,
but rely on memory that is reclaimed at the end of the compilation session.
So during a subsequent compilation in the same process (e.g. when the compiler runs in the
Gradle daemon process), LLVM might call the callback which accesses the reclaimed memory,
which in turn causes the crash.
Fix this by forcing JvmCallbacks to allocate memory that doesn't "expire" at the end of the compilation session.
Including
* Support thread state switching in codegen
* Introduce and use GCUnsafeCall annotation
* Switch thread state in C++ runtime code
Also
* Register current thread in Mark&Sweep tests
* Store MemoryState in Worker instance
* Set worker tid in WorkerInit
These tasks did copy all files from build to build/nativelibs, thus
causing up-to-date checks to fail, and native libs and temporary build
files to be accumulated in recursive directories like
nativelibs/nativelibs/... in both build dirs and dist.
Fix this by copying only relevant files.
These annotations can be used on Objective-C property accessors imported
to Kotlin.
Note: the annotations aren't used in source code, only generated
directly to metadata by cinterop. So this commit doesn't in fact fix
anything but rather makes the implementation less fragile.
See https://github.com/JetBrains/kotlin-native/issues/3336.
builtins "header" is included in both builtin and posix platform libraries, but only posix has declarations for builtin structs (e.g. __va_list_tag). Library resolver by default has no guarantee on order of resolved libraries which causes KT-44295.
To make results of `KotlinLibraryResolver` stable we pass TopologicalLibraryOrder to `getFullList` and specify a dependency of builtin on posix
This is needed for transational period of migrating kotlin repository to compiler with version 1.5
(cherry picked from commit 2836a17952dd47b5b8fe176a0b0374c23567b2ff)
Dmitriy Novozhilov