For some reason, libclang's indexer doesn't index categories with
__attribute__((external_source_symbol(language="Swift",...))),
so we have to additionally enumerate them explicitly.
^KT-49455 Fixed
This aligns with the flag added to kotlinc in:
https://youtrack.jetbrains.com/issue/KT-40670
Hermetic builds would benefit from being able to override dependency paths or airplaneMode using this mechanism:
```
$ bin/cinterop -Xoverride-konan-properties "apple-llvm-20200714-macos-x64-essentials.default=/tmp/llvm;airplaneMode=true" -def baz.def
```
Extract diagnostics from imported modules by instructing libclang to
serialize diagnostics to file. Then deserialize this file and use
first compilation errors in the error message.
^KT-35059 Fixed
Don't use ConcurrentHashMap.computeIfAbsent for typeOf cache,
because the computation may call typeOf recursively for different type
(e.g. C enum var type computation calls typeOf for enum base integer type),
which might cause a deadlock in computeIfAbsent.
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.
Pavel Kirpichenkov