This is the last test in the Klib and was run separately.
Instead, it should be located with 'kotlin-util-io' project which it tests
Merge-request: KT-MR-13978
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Invocation of Logger.fatal() may cause severe side effects such as
throwing an exception or even terminating the current JVM process
(check various implementations of this function for details).
The code that uses Logger.fatal() sometimes expects a particular kind
of side effect. This is totally a design flaw. And it's definitely not
a responsibility of Logger to influence the execution flow of
the program.
The reason of this change is to make messages (especially warnings)
that are reported by the KLIB resolver become visible to the end user.
This can be achieved to forwarding such messages to the appropriate
compiler's components such as
`org.jetbrains.kotlin.cli.common.messages.MessageCollector` and
`org.jetbrains.kotlin.ir.util.IrMessageLogger`.
Also: The default `DummyLogger` should be used as minimal as possible.
Because it just forwards messages to the standard output (console)
where they can remain unattended. When the compiler is executed
from the Gradle plugin such messages appear only in DEBUG Gradle's log.
^KT-63573
`resolveDependencies` showed up as a hotspot when profiling due to `canonicalPath` doing a lot of file system calls.
`fileKey` is more efficient and should guarantee uniqueness (`canonicalPath` may fail in the case of hardlinks).
The new code is 3x faster in our use case.
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
Creating a ZipFileSystem object is an expensive operation.
A cacheable ZIP file system accessor caches ZipFileSystem
objects and may improve the performance of the in place
metadata reading operations from klibs.
Related to KT-51712
* Replace it with KotlinCompilerVersion
* K/N version should be set now with `deployVersion`.
* Cleanup deprecated functions in older versions
of the Gradle plugin
* Cleanup tests for older versions of compiler downloader
Merge-request: KT-MR-8436
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
^KT-44626
Typical use case:
- There are two KLIB libraries: A and B.
- Library A has two versions: A.v1 (older) and A.v2 (newer).
- A.v2 is ABI-incompatible with A.v1.
- B depends on A and was compiled against A.v1.
- An attempt to build the application with A.v2 and B fails with weird error message. It's unclear for end user what's wrong and what needs to be done to fix the issue.
The fix improves error reporting for the following particular cases:
- A symbol that is gone (KT-41378)
- A class that became a typealias (KT-47285, KT-46697)
- A typealias that became a class (KT-46340)
Ensure that Gradle plugin dependencies do not include kotlin-stdlib,
kotlin-reflect and other dependencies that are provided by Gradle
runtime.
^KT-41142 Fixed
Without explicit version we cannot use those modules in buildscripts with Gradle 6.8+ because Gradle doesn't set flag `skipPrereleaseCheck` (previously was named `skipMetadataVersionCheck`). This way we make it compatible with all supported versions of Gradle.
There were unreachable code warnings in printMillisec, and indeed the
variable assignment was never executed, so the function would always
print "0 msec".
- kotlin native versioning support
- disable metadata
- fixes of drop 0 maintanence clause
- support for kotlin.native.enabled flag to switch on/off kotlin native build
- add mode to version generatation to dump version to resourse file
Java Properties format is extremely trivial and does not support any
kind of references or variables. It makes konan.properties repetitive.
This commits adds support of perl-like `$` sigil which allows to
reference properties inside values.
Calling FileSystems.newFileSystem(URI, ...) throws a
FileSystemAlreadyExistsException if a ZipFileSystem for this
URI is already created. We still can use a single instance
of ZipFileSystem by calling FileSystems.getFileSystem. In
this case we use reference counting to determine when this
instance can be safely closed.
But we cannot count references if the same ZipFileSystem is used
from different class loaders. This patch fixes this issue by
creating a file system from Path instead of an URI. Contract of
FileSystemProvider.newFileSystem(Path, ...) doesn't imply throwing
FileSystemAlreadyExistsException.
Issue #KT-37443 fixed
Build systems like bazel rely on the output of a compilation being
deterministic. File checksums determine when an artifact is safe to
cache across builds. One can produce a klib deterministically by using a
fixed timestamp during klib compression.
Before this change:
```
$ kotlinc-native -produce library -output /tmp/first/color.klib Color.kt
$ kotlinc-native -produce library -output /tmp/second/color.klib Color.kt
$ shasum /tmp/first/color.klib /tmp/second/color.klib
bc3f73678ff025cfbec9009f9a851a8ca74e1037 /tmp/first/color.klib
65aa37886fbd53285f2e449a4dab6a2ad02732e6 /tmp/second/color.klib
```
After this change:
```
$ kotlinc-native -produce library -output /tmp/first/color.klib Color.kt
$ kotlinc-native -produce library -output /tmp/second/color.klib Color.kt
$ shasum /tmp/first/color.klib /tmp/second/color.klib
fcba304493916ae34d372188991f87b60a113cf3 /tmp/first/color.klib
fcba304493916ae34d372188991f87b60a113cf3 /tmp/second/color.klib
```
1. If property is absent, or contains empty string or a string consisting only of whitespace characters, Properties.propertyList() should always return empty List<String>.
2. If property starts or ends with whitespace characters, Properties.propertyList() should not include empty-string values for whitespace prefix or suffix.
Pavel Punegov