K/N distPlatformLibs Gradle task dependended on hostInstall and
hostCache. The latter doesn't work (= has incorrect dependencies) on
hosts that don't support compiler caches for the host target (i.e.
Windows).
As a result, running distPlatformLibs task on Windows didn't work,
causing local test runs to fail.
This commit fixes the problem by making distPlatformLibs depend on
`"${hostName}PlatformLibs` instead, so it does the same as before but
handles the non-caching hosts correctly.
It seems that K2 doesn't support `UnitConversionsOnArbitraryExpressions`
experimental language feature (KT-56011), while the test accidentally
relied on it.
Improve the test code so that it doesn't need this language feature
anymore, and enable the test for K2.
^KT-65553 Fixed
Previously, when an Objective-C library had an unused Objective-C
forward declaration (`@class` or `@protocol`), cinterop tool didn't
include it into the resulting klib at all.
This led to a subtle bug (KT-64105). One Obj-C library has unused
Obj-C forward declaration, and another one depends on the first and
uses this forward declaration, e.g. as a function result type.
When building the first cinterop klib, this forward declaration is not
added to `includedForwardDeclarations` in the klib manifest (the
compiler uses this property to decide whether to synthesize the
corresponding class).
When building the second cinterop klib, the forward declaration is not
added to its manifest either, because it is located in the dependency
(and therefore should've been included there).
As a result, the forward declaration is included nowhere, and any
attempt to use it in Kotlin fails, including calling the function from
the second lib.
This commit fixes this bug by including even unused Objective-C forward
declarations, which is consistent with any other kind of declarations
and seems more natural.
^KT-64105 Fixed
Native test infra groups individual tests into compilations, so it
renames packages, patching package and import directives, to avoid
clashes.
This doesn't include "standard" packages. They are distinguished by a
predicate defined in the test infra. This predicate didn't include
`objcnames.*` -- synthetic package provided by the compiler.
As a result, tests importing from `objcnames.*` got those import
directives patched, which was unexpected and could make tests fail.
This commit fixes the problem, making `objnames.*` recognized as
a "standard" package.
When building cinterop klibs, cinterop tool can accept dependencies,
which affects the way it processes the native library.
The test infrastructure allowed to specify cinterop module dependencies,
but didn't actually pass them to the tool.
This commit fixes that.
When running `codegen/box` tests, Kotlin/Native test infrastructure
divides test data files into groups and compiles each group in a single
compilation.
As a result, compilation problem with one test can cause an unrelated
nearby test to fail.
To make this less frustrating, this commit adjusts test failure reports:
it moves the test grouping mention from the bottom of a report to the
top and makes the wording more clear and actionable.
Objective-C has a special type, "instancetype". Generally, it is a type
that matches the method receiver type. So, if `Foo.foo` method returns
`instancetype`, then `Foo.foo()` would be of type `Foo`, while
`Bar.foo()` would be of type `Bar` (where `Bar` is a subclass of `Foo`).
Surprisingly, `instancetype` can be used not only as a return type, but
also somewhere inside a return type. cinterop wasn't ready for this.
This commit expands implementation of `instancetype` in cinterop to
cover more cases.
^KT-59597 Fixed
e5ae32c removed bitcode embedding from tests. In particular, that commit
disabled bitcode embedding when compiling Swift code (e.g. in ObjCExport
tests).
It seems that bitcode embedding also enables adhoc codesigning in the
linker.
The linker doesn't seem to do adhoc codesigning by default for tvOS
arm64 simulator target, and without a signature the binaries can't run
on the simulator.
So disabling bitcode embedding also disabled adhoc codesigning and made
the tests fail on that target.
Fix this by explicitly passing `-Xlinker -adhoc_codesign` when compiling
Swift code in tests.
ObjCExport accessed `__NSCFBoolean` using
`objc_getClass("__NSCFBoolean")`. This class is a private API.
Remove this private API usage by getting the same class from
`[[NSNumber numberWithBool:YES] class]` instead.
Also remove `__NSCFBoolean` from the related error messages.
`__NSCFBoolean` didn't cause Kotlin-compiled apps to be rejected by
Apple, but this commit reduces the risk that this might happen in the
future, and addresses related user concerns.
^KT-62091
- ObjCExport tests for numbers RTTI conversions didn't really check
RTTI, because of a compiler optimization. Fix this by converting to
Any.
- Also add more tests that specifically check that bool `NSNumber` get
dynamically converted to `kotlin.Boolean` box. Those tests can't be
affected by possible future compiler optimizations.
Xcode 14 deprecates bitcode embedding, and Xcode 15 removes support
for it. Therefore, testing bitcode embedding in Kotlin doesn't make
much sense.
This commit removes most of test code that enables bitcode.
^KT-61875
Synchronously copy system properties before iterating over them, because
other thread sometimes tries to modify them in the meantime, which leads
to ConcurrentModificationException otherwise.
Our sysroot for mingw_x64 still requires -femulated-tls. For C++ code
as well. Without it the test fails with
lld-link: error: undefined symbol: std::__once_call
^KT-46612
The build script manually specifies which directories are parts of
which source sets. And it did that wrong: all directories were just
added to the nativeMain source set.
This was an incorrect configuration (matching expect and actual were
getting into the same source set), and K2 compiler was not really happy
with that.
This commit fixes the correspondence between source sets and source
directories in kotlin-native/performance/framework build script, thus
fixes the build for that benchmark with K2.
Those benchmarks are built with bootstrap KGP and snapshot compiler.
Currently the former is K1, while the latter is K2. As a result, the
build fails because K2 compiler needs -Xfragment-sources argument,
while K1 uses -Xcommon-sources. So KGP passes the latter, while the
compiler expects the former.
Fix this by forcing KGP to use K2 for benchmarks in performance/
This can be reverted once bootstrap is updated to 2.0.0.
benchmarksAnalyzer is built with bootstrap KGP and snapshot compiler.
Currently the former is K1, while the latter is K2. As a result, the
build fails because K2 compiler needs -Xfragment-sources argument,
while K1 uses -Xcommon-sources. So KGP passes the latter, while the
compiler expects the former.
Fix this by forcing KGP to use K2 for benchmarksAnalyzer.
Previously filecheck_signext_zeroext_objc_export test was disabled
after making one-stage compilation mode implemented through two-stage
mode (KT-59245).
That change made the compiler sort the methods, and filecheck patterns
didn't match that order after that.
This commit fixes the test by adding sorted prefixes to method names,
so sorting alphabetically them doesn't really change the order.
There was a minor mistake in the build script configuration, leading to
a missing task dependency when running the tests with
`-Pkotlin.native.home=`.
More specifically, the build script was checking if the cross-dist for
the main tests target (`-PtestTarget=`) is in place, but instead it
should have checked if the cross-dist for the test cross-target
(`test.targetName`) is in place.
This commit fixes the check, and thus adds the missing task dependency.
4774912f updated the patterns for the filecheck_constants_merge test,
because the commit slightly changed the code generated for TypeInfo.
But the test update was made with a copy-paste-related mistake.
As a result, the test didn't work with `-Ptest_with_cache_kind=static`.
This commit fixes this, buy reverting the unintended changes in
the filecheck patterns.
Currently, when generating a TypeInfo with a vtable attached, the K/N
compiler generates two globals to the resulting LLVM module:
- "ktypeglobal:$fqName#internal" -- an internal global of the aggregate
type (TypeInfo+vtable)
- "kclass:$fqName" -- an internal or hidden alias pointing to the
TypeInfo part of that global
The reason for emitting two globals is to have everything strict-typed,
since other LLVM modules might import the kclass as a TypeInfo.
Importing an aggregate TypeInfo+vtable global as a TypeInfo global works
too, of course. It is just a little bit less clean.
The new Xcode 15 linker now emits symbols for the ktypeglobal to the
symbol table, including an STSYM. This happens for classes compiled to
cache, when the kclass is hidden, not internal.
The problem is: for some reason, such an STSYM for
"ktypeglobal:kotlin.String#internal" makes lldb find a wrong address
(0xffffffffffffffff) for "kclass:kotlin.String", despite those being
two different symbol names. This seems to be related to them having
the same address though.
The K/N lldb script, konan_lldb.py, uses "kclass:kotlin.String" to
determine if an object is a string, in order to display it properly.
Therefore, using the new Xcode 15 linker when compiling with caches
makes the debugger unable to display string variables properly. As a
side effect, this also breaks displaying array-typed variables (because
the script first checks if an object is a string).
This commit fixes this by removing ktypeglobals completely, making the
compiler emit only a kclass as an aggregate global directly.
Now, there are other ways to fix the problem. For example, making the
ktypeglobal private instead of internal, or making konan_lldb.py use a
runtime function instead of querying "kclass:kotlin.String" directly.
But it seems that LLVM aliases are not common on darwin platforms. For
example, Clang doesn't support `__attribute__((alias(...)))` on these
platforms.
So it is safer to just stop using aliases here.
^KT-61417
Building Kotlin/Native itself involves running cinterop in the Gradle
daemon process to reduce build time.
But this optimization appears to be incorrect when reusing Gradle daemon
for subsequent builds.
This commit disables the optimization by default, keeping enabling it
possible using `kotlin.native.allowRunningCinteropInProcess=true`
project property.
For more details see ^KT-61300
CompareDistributionSignatures task is used to compare Native platform
libraries contents against a previous version.
Under the hood, it runs the klib tool to get a library contents. But it
didn't check the exit code, so if klib tool failed, the task could
mistakenly indicate that there are no differences in platform libs.
Fix this by checking the klib tool exit code and failing if it is not
zero.
Because of KT-50547, this test doesn't work on Windows with HMPP
enabled.
Previously, because of that HMPP was disabled for all samples.
But now disabling HMPP is no longer possible, so ce9a45b enables HMPP
for samples.
Disable echoServer sample on Windows to workaround ^KT-50547
Now (mostly after 3f3f6eb) cinterop adds ExperimentalForeignApi to all
Kotlin declarations it generates from C and Objective-C libraries,
except for the platform libraries.
This commit changes the KDoc for ExperimentalForeignApi to reflect that
change.
^KT-58362
3f3f6eb marks all cinterop-generated declarations with
@ExperimentalForeignApi. As a result, all usages of such declarations
have to opt-in explicitly. This commit adds those opt-ins to all
usages in the Kotlin Gradle plugin integration tests.
^KT-58362
3f3f6eb marks all cinterop-generated declarations with
@ExperimentalForeignApi. As a result, all usages of such declarations
have to opt-in explicitly. This commit adds those opt-ins to all
usages in the performance tests.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
`headers.x86-64` property in a cinterop .def file is not actually used
by cinterop. `headers.x64` should be used instead.
This commit removes it completely instead of renaming -- no functional
changes are done.
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. This commit implements adding the annotation.
Nested declarations don't get the annotation, because they inherit the
opt-in requirement from the enclosing classes implicitly.
The annotation is not added to platform libraries, as intended. See
previous commits.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. To make this possible to implement in a
non-intrusive manner, this commit enables adding annotations to some of
the existing Stub IR nodes.
After that, one can add annotations to all generated declarations with
a simple post pass.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. This commit supports this annotation in
cinterop intermediate representation -- Stub IR.
^KT-58362
Use -Xdisable-experimental-annotation when generating platform libs.
As a result, unlike all other cinterop libraries, declarations in
platform libs won't require ExperimentalForeignApi opt-in
^KT-58362
It disables adding `ExperimentalForeignApi` opt-in to declarations
generated by cinterop.
Main use case is platform libraries, which are not supposed to have this
annotation. Applying the flag to user cinterop libraries is discouraged
and effectively means opting in.
^KT-58362
Don't make Docker container copy artifact to a host directory mounted
with -v, because this fails due to a file permission issue:
build is run by a regular user, but the volume directory inside the
container is owned by root.
Instead, make the host copy the artifact from the container.
Also, make the container print the artifact path before that.
Just in case, in order to easily copy file manually, should something
go wrong.
^KT-58864
The previous URL no longer works. The isl project has moved hosting to
sourceforge.io. Update the mirror accordingly.
This is fixed in Crosstool-NG 1.25.0, but the URL is included in config
and needs to be updated there.
Note: to make the rest of toolchains buildable, the same change should
be applied to their configs.
See also https://github.com/crosstool-ng/crosstool-ng/pull/1614.
^KT-58864
Ubuntu 14.04, used before, has expired root SSL certificate for
Let's Encrypt. As a result, OpenSSL couldn't verify SSL certificates
issued by Let's Encrypt, failing, in particular, kernel download.
^KT-58864
Replace `#include <inttypes.h>` with `cinttypes`.
Improve other includes in the same file.
^KT-58864
Co-authored-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
An expect class might lack some details and thus seem incorrect to the
compiler, while the corresponding actual class is totally fine.
Due to the specifics of the compiler, this happens more often then it
should (because the compiler actually always analyzes expects along
with actuals, with most references actualized).
For example, in KT-52882 the compiler analyzes an expect class
(TestImpl), but the class refers to the actual interface Test as its
supertype, meaning that the compiler sees TestImpl as a class inheriting
an Objective-C protocol but not an Objective-C class, which is
prohibited. While the actual class has its super types in order.
So, in reality, from both actualized and non-actualized points of view,
the code is totally correct, and the error was reported only because of
the way the compiler handles multiplatform.
Those compiler checks only matter for the actual class anyway, so
disabling them for expect classes is harmless.
^KT-52882 Fixed
Also, adjust NativeIrLinkerIssuesIT after 5f3dad1. See the explanation
below.
5f3dad1 makes -Xlazy-ir-for-caches disabled by default. So the compiler
now deserializes different subsets of IR and in different orders.
As a result, the error message for a test changes. Both error messages
(before and after this commit) are correct, and the selection depends
on the IR deserialization strategy.
Moreover, this commit changes the expected error message to the initial
version, used before -Xlazy-ir-for-caches was introduced.
After recent changes (0cfb801) println got inlined into the checked
function. As a result, the test became affected by KT-59552.
Fix the test by moving println out of the checked function.
Currently, if a Kotlin object happens to have null for an associated
object but FLAGS_RELEASE_ON_MAIN_QUEUE flag set, GC will dispatch
Kotlin_ObjCExport_releaseAssociatedObject(null) to the main thread
anyway.
This couldn't happen before, but can now, with disposeObjCObject.
The commit prevents this, by moving the null check out from
Kotlin_ObjCExport_releaseAssociatedObject to call sites.
^KT-59134
For a Kotlin wrapper of an Objective-C object, this functions zeroes
and releases the strong reference from the Kotlin wrapper to the
Objective-C object.
Usually, such a release happens only when the Kotlin wrapper is GCed.
So using this function can help that happen sooner.
^KT-59134
The overall concept of "endorsed" libraries is currently unmaintained
and non-reviewed.
kotlinx-cli is in its alpha, and is available from Maven.
See also KT-54098.
Also, fix KGP IT for linkage error messages:
the message text in the presence of compiler caches was changed because
of ab89203, and this commit effectively reverts expected message changes
made in ebaa09a.
It is not supposed to work with K1 on Native due to test infrastructure
limitations, and actually fails in one of the compilation modes in
nightly tests.
This option makes the compiler use Kotlin/Native-provided LLVM
instead of Xcode-provided LLVM when compiling bitcode to machine code
for Apple targets.
^KT-54799 Fixed
On some platforms, `NSUInteger` is 32-bit, while the objc_direct tests
expected it to be represented as `ULong`. So the tests failed on those
platforms.
Fix the tests by replacing `NSUInteger` with `uint64_t`.
tryRenderStructOrUnion can return null for a struct or union to indicate
that passing it by value to or from C is not supported (e.g. it has
bitfields).
It incorrectly handled the case when passing a nested struct or union by
value was unsupported -- instead of null, it returned incorrect struct
declaration.
As a result, when passing such a complex struct or union by value to or
from C, the backend generated C stubs with syntax errors, which resulted
into obscure compilation error ("unable to compile C bridge").
This commit fixes this case in tryRenderStructOrUnion function, and thus
makes the compilation error message more understandable.
^KT-55030
Kotlin/Native compiler can compile source files directly to a native
binary (e.g. an executable or a framework). This is the so-called
"single-stage" compilation mode. It is used only in the command-line
compiler, while Kotlin Gradle plugin always produces an intermediate
klib first, and then compiles it to a native binary ("two-stage"
compilation mode).
When running Kotlin/Native compiler with '-language-version 2.0' in the
single-stage compilation mode, it in fact doesn't use the new K2
frontend. This is misleading and error-prone.
To address this problem, the commit prohibits the single-stage
compilation with '-language-version 2.0'. This affects only the
command-line compiler, and shouldn't affect compilation with Gradle.
^KT-56855
This commits adds a Gradle project property 'kotlin.native.tests.tags',
which can be used when running :native:native.tests:test task to filter
tests by tags. The property value can contain an arbitrary JUnit tag
expression. See
https://junit.org/junit5/docs/current/user-guide/#running-tests-tag-expressions
for more details.
With this task, we can be more sure that TeamCity runs all the tests.
Other test tasks in :native:native.tests project run only tests with
specific pre-defined tags, so running them on TeamCity was discovered to
be more error-prone in that regard, and is generally less flexible.
