It was decided to leave this code as is, because supporting
it would probably require introducing Implication-statements,
but this is not a good-enough use-case for such work.
Before this change `ARGUMENT_TYPE_MISMATCH` would complain that
`Y` "is not a subtype of" `Inv<Y>`, because the function would only
check immediate bounds of the type parameter `Y`. `chosenSupertype`
would be `X`, not `Inv<out kotlin/String>`.
^KT-60056
The thing is, in a box test there is a proper
`UNRESOLVED_REFERENCE` on `M2().a.m2()` in K1 as well,
but it's not present in diagnostic tests. And also,
there's no error in the Kotlin IntelliJ plugin when
viewing such code.
It looks dangerous, but since this code is about
classes with identical fqNames, and since nothing
sus is really compiled, we can probably ignore this
problem. It's unlikely that it impacts much.
`invoke()` function of functional types is always defined
in such a way that its explicit receiver comes as the first
value parameter. Extension-function types contain the very
same `invoke` function, they just additionally have the
`@ExtensionFunctionType` annotation.
In the related test there is such an `invoke` function and
in the presented call its explicit receiver is the anonymous
function `fun Int.() = 1` itself. So the safe-checked `1`
^KT-60056
For per-file caches the data race is still there, but since per-file caches are
only used for incremental compilation, it's ok to leave it as is for now (we cope
with the data race by using a separate folder for each Gradle task).
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
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>
This is already the case for Kotlin/JS.
This is required for fixing KT-63670: `linkViaSignatures` implies that
`SymbolTable` is used in FIR2IR, and in case if two declarations
have the same `IdSignature`, we have a crash in FIR2IR:
exception: java.lang.IllegalStateException: IR declaration with
signature "/foo|foo(){}[0]" found in SymbolTable and not found in
declaration storage
If we're not using SymbolTable, FIR2IR finishes successfully, and we can
safely proceed to the KLIB serialization stage, at which point we
can show the user a diagnostic about clashing signatures.
Since we've disabled SymbolTable, we also needed to fix the logic that
relied on its presence. Fortunately, such logic only includes
filtering out unused libraries. Instead of iterating over symbols in
SymbolTable, we iterate over cached symbols in Fir2IrDeclarationStorage
and Fir2IrClassifierStorage, which seems to do the trick just as well.
Vladimir Sukharev