If we are compiling metadata, make synthetic forward declarations
`expect`, because otherwise `getFirstClassifierDiscriminateHeaders`
would prefer it over a "real" `expect` declaration from a commonized
interop library, which would ruin the whole idea of using synthetic
forward declarations only when no proper definitions are found.
^KT-51377 Fixed
It included "konan/lib/*.jar", which became incorrect after adding
kotlin-native-compiler-embeddable.jar to K/N dist in 2baf344f5f:
after that, the classpath included both kotlin-native.jar and
kotlin-native-compiler-embeddable.jar, so it contained duplicating
classes.
Fix this by choosing particular .jar files from konan/lib, and use
kotlin-native-compiler-embeddable.jar.
Custom dist is already in place and has the compiler, so we don't have
to build and copy the compiler to dist.
Moreover, if we do copy it, it might overwrite the compiler files
already loaded by this Gradle process (including the jar loaded to the
custom classloader), causing hard-to-debug errors.
To workaround this, we disable the distCompiler task and don't add any
dependencies to it when custom dist is used.
It is `@OutputDirectory`, so Gradle can invoke it early, even before the
klib itself is built.
Instead of reading `uniqName` from klib files, require specifying it
explicitly.
Link libllvmstubs.dylib to `$sysroot/usr/lib/libc++.1.dylib`
instead of `$llvm/lib/libc++.1.dylib`.
The latter has `@rpath/libc++.1.dylib` as install name, so
the dynamic linker was unable to find it when loading
libllvmstubs.dylib on macOS 12.3.
^KT-51359 Fixed
To keep it consistent with Gradle plugin. See ^KT-48595
CLI compiler launched with arguments obtained from Gradle log
should be able to handle plugins.
Force generation of ARM instruction set for iosArm32 and
watchosArm32 targets for C++ code. There is no need for such
adjustments for Kotlin code because we don't specify any target
features in IrToBitcode and compiler backend infers target features
from target architecture (which is armv7* and not thumbv7).
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
The Objective-C methods for Kotlin data class componentN methods
shouldn't have been generated in the first place -- the corresponding
Kotlin methods are required to make the destructuring work in Kotlin,
and don't help in Objective-C or Swift.
Calling them manually from Objective-C or Swift doesn't make much sense.
So now we deprecate this, in order to remove these methods from
Objective-C header completely later.
^KT-42641
^KT-49516 Fixed
Vyacheslav Gerasimov