We want to move from current compilation pipeline
that is defined in TopLevelPhases.kt to a "dynamic" one.
The main drawback of the current one is that it is built
around single Context, single IR module, single compiler output, etc.
It is now as flexible as Kotlin/Native compiler requires.
For example, it is pretty hard to support multiple Apple frameworks
or a proper separate compilation.
To mitigate this problem, we are going to move to a new "dynamic"
compiler pipeline that relies on an explicit data passing between
different compiler phases. For example, it allows to use single phase
output as an input for multiple independent subsequent phases. Or
vice versa, e.g. use outputs of multiple "produce object file" phases by
a single linker phase.
This commit introduces `CompilerDriver` hierarchy which is required
during transition period.
A ModuleDescriptor is needed to create external package fragments with
descriptors (see JvmSymbols.kt). Descriptorless external package
fragments can fail in code using obsolete descriptor based APIs.
Makes build be able to publish bundles to the maven. It uses common
properties and settings as all other Kotlin publications.
Add usage of the Gradle base plugin and correct version and name setting
for archive tasks
Usage of this function is unsafe because it does not have native compiler
support. This means that compiler won't report UNCHECKED_CAST,
CAST_NEVER_SUCCEED or similar diagnostics in case of error cast
(which can happen immediately or after some refactoring of class hierarchy)
E.g. when substituting T -> Array<T>, write the bytecode for the
Array<...> part for typeOf.
This fixes various issues where either Array nesting levels, nullability
information (for typeOf), or entire reification markers were missing,
causing incorrect outputs ranging from missing `?`s to missing `[]`s to
just reified types not really being reified.
^KT-53761 Fixed
After introducing watchOsDeviceArm64 target it conflicted with existing
watchOsArm64 target. Because both having the same Konan Architecture as
Arm64. This is not entirely correct and actual
architectures are different. So it requires more precise macros for
fat framework.
* __ARM64_ARCH_8_32__ for `watchOsArm64` which is based on `arm64_32`
* __ARM64_ARCH_8__ for other arm64 devices including `watchOsDeviceArm64`
^KT-53107
When coroutine class is created, it's made child of SuspendFunction
class. Normally, SuspendFunction class can't be already lowered,
but if we are compiling stdlib it can happen. And if it is
bad fake overrides would be created before this commit.
Unfortunately, as problem can happen only during stdlib compilation,
no specific test can be added.
Sergey Bogolepov