- Make the messages that are reported by KLIB resolver prettier
- For those messages that affect the resolve process add
prefix "KLIB resolver: "
- Don't log warning on duplicated libraries on the classpath. This
does not make any sense.
^KT-63573
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
Native bitcode files were moved out of the stdlib to the default
location of bitcode files in the dist.
Now it is possible to build stdlib separately and once as a klib
without bitcode files inside.
This corrects the type given to GEP2 when initializing a stacklocal
array. This issue only cause problems when bitcode gets written before
any of the optimization passes, in which case it will fail on LLVM
validation when reading the bitcode back in on a subsequent pass.
Swift Export Frontend generates a Kotlin file/library that contains a
set of simple bridging functions that connect Swift wrappers to their
Kotlin counterparts.
There are certain requirements for these wrappers:
1. They should not be DCEd when compiling a binary library.
In other words, these functions are roots.
2. They should provide a stable simple binary name.
3. Their signatures should be much simpler and restricted comparing to
other Kotlin functions.
Altogether, these requirements should be covered by introducing the new
ExportedBridge annotation.
Note: Frontend checks of ExportedBridge functions are not implemented
yet.
We can reuse existing static/dynamic library output kinds for
the Swift Export. The only change we have to make is to make generation
of C interface opt-out by moving it under the binary option.
As a side effect, it allows evolving C Export in the future by
introducing new option variants.
The entire concept of conventions is deprecated in Gradle. Here it was making the build logic implicit and hard for understanding
^KTI-1473 In Progress
It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
The -Xcoverage feature has not worked and has been disabled for a while.
This fix removes it, and all of its uses.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-821
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
LLVMConstGEP2 and LLVMConstInBoundsGEP2 were forward declared in
LLVM-11, but not implemented until LLVM-14. This patch adds these along
with the missing LLVMAddAlias2. All three implementations are copied
from llvm branch release/14.x
Vladimir Sukharev