At the moment, SubclassOptInRequired is marked with the
ExperimentalSubclassOptIn annotation. However, it does not work
as expected due to a missing opt-in error. To use SubclassOptInRequired,
an explicit opt-in is necessary because SubclassOptInRequired is an
unstable feature now.
^KT-64739
Including checks:
* running embedAndSign through a build phase
* running embedAndSign through a scheme pre-action script
* running embedAndSign through a scheme pre-action script and using Kotlin framework in local SPM package
* absense of explicit '-framework' linker flag
^KT-62376
^KT-63819
K2-only issue. In an incremental build, sourceSet boundary isn't
preserved in certain conditions:
SourceSet A depends on SourceSet B
A and B overload a function, for example:
A -> fun foo(p: Parent) // (1)
B -> fun foo(c: Child) // (2)
If some source file in A is calling foo(..), only (1) is supposed to be visible
for that call site.
However, if
a) it is an incremental build,
b) the declaration of (1) is not a part of the compilation set, and
c) call to foo(c: Child) is applicable,
then (2) would be called from the generated code. So, the build result is not
consistent between the full build and an incremental build.
As a workaround, we fallback to a non-incremental build, if any source from A
needs to be compiled.
To enable "risky" incremental builds, use Gradle property
kotlin.internal.incremental.enableUnsafeOptimizationsForMultiplatform=true
^KT-62686
^KT-63837 Fixed
Merge-request: KT-MR-13695
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Apparently, using such an approach is a popular case especially for
configuring 'dependsOn' parameter. And we should simplify user migration
to more restricted DSL.
^KT-64722 Verification Pending
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.
These methods are only added to provide more user-friendly error
when user tries to configure JVM toolchain in Kotlin target DSL.
^KT-64629 Verification Pending
Couldn't reproduce the issue in tests or with the reproducer. Most likely the problem was on my side.
^KT-63970 Can't Reproduce
Merge-request: KT-MR-13673
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Yahor Berdnikau