This commit handles subtle situation when K1 represents flexible type
arguments as just T..T?, but K2 does it as T&Any..T?.
This can provoke a type like Captured(*)&Any..Captured(*)?,
and before this commit we couldn't find recursion inside Captured(*)&Any.
This could lead to explosions inside type system and inference errors
#KT-60581 Fixed
If the modality of a property is not final, the modality of the dispatch
receiver can be used to determine if the property is stable. When
looking up the dispatch receiver symbol, make sure to unwrap the lower
bounds of flexible types.
^KT-61735 Fixed
The main reason of this commit is the fact that it makes no sense
to create type checker forks in case of two or more types which equal
each other.
Also, this commit fixes the test taken from KT-59514
(see interconnectedGenerics.kt test changed in this commit).
In this particular case we have a subType of C.WithL<Pr!, En<Pr>!>,
and a superType of R<T> with a superType constructor R.
In findCorrespondingSupertypes we get *two* similar supertypes here,
both have a string representation of:
R<Il<@EnhancedNullability En<Pr>!>!>.
If we create two forks because of it, we get NEW_INFERENCE_ERROR
with the following subtyping violation:
Il<@EnhancedNullability En<Pr>!>! <: En<Pr>!.
NEW_INFERENCE_ERROR happens because we make a redundant fork in that case,
but the forks should still work despite it (see KT-62333).
These two types appear due to the content of FirCorrespondingSupertypeCache.
For a key C.WithL and a superType R it stores the following pair of supertypes:
- R<Il<@EnhancedNullability S>!>
- R<Il<(@EnhancedNullability S & Any, @EnhancedNullability S?)>!>
After substitution of S to En<Pr>! they become similar.
NB: if we change jspecify severity level from strict to warn,
then 'R<Il<(S & Any, S?)>!>' is the only remaining supertype,
and @EnhancedNullability annotation is no more in use.
The type hierarchy in this example looks like:
WithL<T, S> <: CanWithB<T, S>, R.F<S, Il<S>>
CanWithB<T, S> <: R.F<S, Il<S>>
R.F<S, Il<S>> <: R<Il<S>>
So R is reachable by two different ways, via CanWithB and directly via R.F.
#KT-59514 Fixed
The build script manually specifies which directories are parts of
which source sets. And it did that wrong: all directories were just
added to the nativeMain source set.
This was an incorrect configuration (matching expect and actual were
getting into the same source set), and K2 compiler was not really happy
with that.
This commit fixes the correspondence between source sets and source
directories in kotlin-native/performance/framework build script, thus
fixes the build for that benchmark with K2.
Those benchmarks are built with bootstrap KGP and snapshot compiler.
Currently the former is K1, while the latter is K2. As a result, the
build fails because K2 compiler needs -Xfragment-sources argument,
while K1 uses -Xcommon-sources. So KGP passes the latter, while the
compiler expects the former.
Fix this by forcing KGP to use K2 for benchmarks in performance/
This can be reverted once bootstrap is updated to 2.0.0.
For some reason the practice is to configure the K2
diagnostics tests as "alongside" and instruct K1
tests to ensure there are no unexpected differences
in the sources. But someone may still forget there is
something that they need to configure in the K1 runners.
as those experimental APIs have shown to negatively affect usages
of stable APIs (because of resolve confusion), whilst also
failing to address popular use cases.
KT-61636
KT-61355
KT-61368
...actualized via typealias. This caused false-positive report of
`ACTUAL_ANNOTATION_CONFLICTING_DEFAULT_ARGUMENT_VALUE`.
In such case it's incorrect to compare signatures, because classes have
different `ClassId`s. Instead, classes could be compared using
`areCompatibleExpectActualTypes` which actualizes both types, and
then enum value names compared.
^KT-62104
^KT-59940
This fixes failing test
`FirOldFrontendMPPDiagnosticsWithPsiTestGenerated.DefaultArguments.testAnnotationsViaActualTypeAlias2`.
It started to fail after commit 4e08cafc78
"[FIR2IR] Get rid of IrSymbol.owner usages in Fir2IrLazyClass"
where in Fir2IrLazyClass `declarationStorage.getIrConstructorSymbol`
was changed to `declarationStorage.getOrCreateIrConstructor`.
Before change, value parameters were initialized in
`Fir2IrLazyConstructor#valueParameters` where
`forcedDefaultValueConversion` was passed.
After the change parameters via
`Fir2IrCallableDeclarationsGenerator.declareParameters` where
`forcedDefaultValueConversion` is not passed to method.
^KT-62104 Fixed
Regex OR ('|') has weird precedence rules and previous version of regex
were essentially checking two alternatives:
- kotlin-native-prebuilt-.*-1\.9\.3[0-9](-.+)?
- 2\.0\.0(-.+)?
This is obviously incorrect, but it won't manifest on machines that
already downloaded that artifact to `.konan` via the build without
verification-metadata.xml
Since Xcode 15 the iconv APIs operate on an opaque type __tag_iconv_t* instead of
void*. This causes a runtime exception in older Ktor versions which
depended on iconv.
^KT-62286
benchmarksAnalyzer is built with bootstrap KGP and snapshot compiler.
Currently the former is K1, while the latter is K2. As a result, the
build fails because K2 compiler needs -Xfragment-sources argument,
while K1 uses -Xcommon-sources. So KGP passes the latter, while the
compiler expects the former.
Fix this by forcing KGP to use K2 for benchmarksAnalyzer.
as this will result in losing transitive dependencies from said
project dependency.
KT-59020 is now fixed by detecting this case
before creating the 'IdeaKotlinUnresolvedBinaryDependency'
Caused by: KT-59020
^KT-62029 Verification Pending
Before this commit, we allowed access to outer class type parameters
during resolve of type parameter bounds of a nested class.
In fact, outer type parameters are accessible in this situation
only if it's an inner class (or a local class).
This commit forbids such a usage. In the earlier fix of KT-57209
the same was done for regular type reference resolve.
#KT-61459 Fixed
#KT-61959 Fixed
Mikhail Glukhikh