This way, even if the whole qualifier is not selected, but some of its
parts are, the reference shortener will correctly find and shorten
those parts
^KTIJ-28080 Fixed
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
Instead, use specific resolution mode handled by call completer.
Mostly, it's done for simplification of PCLA implementation because
otherwise we would need to track how PCLA inference session and the
one for augmented should be combined.
But just independently of this, not using inference session here,
it looks just simpler.
^KT-59791 In Progress
Initially, it was a bug caused by unfortunate copy-paste, but there were
no tests for this because mostly `delegation` operators are functions
But after PCLA is implemented, many tests start failing
For example, FirPsiOldFrontendDiagnosticsTestGenerated.Tests.BuilderInference.OneParameter.OneTypeVariable.OneTypeInfoOrigin.TypeInfoSinks.testImmutableProperties
^KT-59791 In Progress
This was never semantically correct, but was not important
before KT-63644, as they were immediately dropped after that anyway.
After KT-63644, they were used to compute fake overrides inside them,
which were later matched against actual class, which can
produce false-positive matching errors.
^KT-64835
`AtomicfuNativeTestGenerated` test depends on classes from Native
modules, which are not present in the JPS build. Which means that this
class should be excluded from the compilation, so "Build project"
wouldn't fail on it
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.
Jinseong Jeon