This commit is literally this shell command:
```
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualAnnotationMatchChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualAnnotationMatchChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualCompatibilityChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualCompatibilityChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualCompatibility.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCompatibility.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualMatchingContext.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMatchingContext.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualMemberDiff.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMemberDiff.kt
```
Motivation: KMP is going to evolve in K2 a lot. But we don't want to
touch K1 version of KMP. That's why it's easeir to just copy-paste
expect-actual matcher into K1 flavor
There's no module kind check for IDE at the moment: IDE modules don't
have access to compiler arguments or configuration. K1 currently doesn't
report the diagnostic either. See KTIJ-27279 for more details.
This commit repeats K1 behaviour: K2 IDE won't fail because of the
missing service, but the diagnostic won't be reported in IDE, only
during compilation.
KT-61615
it's useful for IDE's features such as write UAST or refactorings
^KT-62302 fixed
Merge-request: KT-MR-12414
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
When computing the conversion type for a type operator call, the
argument needs to be fully unwrapped before getting the resolved type.
This avoids the situation when the argument is a when-subject and the
assumed original type is not correct. Before, only smart-casts were
unwrapped, and this change will also unwrap when-subjects (as well as a
few other FirExpressions).
^KT-62114 Fixed
There are conditions where the data-flow analysis for a control-flow
graph node is delayed. Make sure that when completing a graph, all nodes
within the graph have completed their data-flow analysis.
^KT-61794 Fixed
This increases the boundary for the next GC scheduling by how much is
estimated is currently being wasted by the allocator due to paging. This
is necessary, since the gc scheduling boundary is set based on the size
of the live set at the last GC, while the current memory use is only
tracked in whole allocator pages. This patch avoids some of the
situations where the GC would be triggered again immediately upon
completion, which happens with many sparsely filled pages.
After the change to track allocations in big chunks (KT-57773), the
scheduler no longer had information about how much of the allocated
memory was used on live objects, which lead to a lot of extra memory
usage (KT-61914). This patch adds the tracking of live objects size to
sweeping, which is enough to mitigate the problem.
co-authored by Alexander Shabalin
^KT-61914
This makes sense as such callables do not conflict on their use-sites,
because a hidden callable loses to a non-hidden one when doing
overload resolution.
We achieve this by not considering such callables as conflicting when
collecting them in FirDeclarationCollector.
A callable is hidden if it will be hidden from the overload resolution,
meaning it has a `Deprecated` or `DeprecatedSinceKotlin` annotation.
NB: this also impacts `REDECLARATION` diagnostic for properties, as they
can also be marked as `Deprecated`.
NB: this change ignores local callables, as they are ignored
w.r.t. `Deprecated` in K2.
^KT-22004 Fixed
These two tests are now failing with IR fake override builder because
e.g. the fake override `MyMutableList.foo` has two overridden symbols:
`MyList.foo` and `MyMutableCollection.foo`, as opposed to the normal K2
mode which only has the former.
This seems to only affect the printed IR dump. Note that in K1 there
were two overridden symbols as well.
Extract the common logic of remapping fake overrides into a function.
Also, slightly change behavior of the check to be stricter: now it's
using `as S?` instead of `as? S`, which means that if the remapped
symbol is present in `fakeOverridesMap`, then it must be of the same
type.
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
Nikita Bobko