Now, we detect clashing signatures during serialization to KLIB and
report a compiler error if two or more declarations have the same
`IdSignature`
For example, for the following code:
```kotlin
@Deprecated("", level = DeprecationLevel.HIDDEN)
fun foo(): String = ""
fun foo(): Int = 0
```
the compiler will produce this diagnostic:
```
e: main.kt:1:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
e: main.kt:4:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
```
Note that we report this diagnostic during serialization and not earlier
(e.g., in fir2ir) for more robustness, so ensure that we check
exactly the signatures that will be written to a KLIB.
If we later introduce some annotation for customizing a declaration's
signature (e.g., for preserving binary compatibility), this
diagnostic will continue to work as expected.
^KT-63670 Fixed
* 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>
Enable custom allocator with -Xallocator=custom.
If the gc is cms (default):
* a patched version of the memory manager is used that does not build a
list of allocated objects.
* a patched version of the cms is used that defers to the allocator for
sweeping.
Otherwise, a warning is printed, and the allocator is used using the
standard api.
Design doc:
https://docs.google.com/document/d/15xMp-nE-DWL8OrtOc8DoXB80AHUphFICEGjj5K0aNFc
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-546
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
`-Xomit-framework-binary` is useful when the user does not care about
generated machine code, but only about its public interface.
Current use-case is for development purposes only: to iterate faster
on ObjCExport. But potentially it can be turned into user-facing feature
With new syntax each plugin should be registered in separate argument with syntax
`-Xcompiler-plugin=classpath1,classpath2[=argument1=value1,argument2=value2]`
Adding -Xbundle-version and -Xbundle-short-version-string
compiler arguments. These can be used in the freeCompilerArgs
in the gradle configuration to control the version strings
in the Info.plist in generated frameworks.
```
version = "1.0"
macosX64("native") {
binaries.framework {
compilation.kotlinOptions.freeCompilerArgs += "-Xbundle-version=$version"
}
}
```
^KT-33117 Fixed.
The Kotlin/Native compiler uses `.deleteOnExit()` as a substitute for
"delete after the compilation". But when the compiler runs in a Gradle
daemon, `.deleteOnExit()` means "delete on Gradle daemon exit", which
might be not soon. If a single Gradle daemon runs the compiler many
times, the remaining temporary files can consume quite a lot of disk
space. For example, this is the case for the Kotlin build.
Replace some of `.deleteOnExit()` calls with an explicit removal of
temporary files at the end of a compilation session.
This check is no longer obsolete since language version 1.3 support is
restored for Kotlin/JVM, but JS and Native never supported LV 1.3.
This is a partial revert of 0213c25c9b,
without the diagnostic in K2JVMCompilerArguments (which is not needed
since the earliest supported LV is 1.3).
#KT-50695 Fixed
Sergej Jaskiewicz