It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
The trove4j library is licensed under LGPL, and that causes some troubles while working with it. The fastutil library provides the same functionality in the context of our needs, and is licensed under the Apache license.
^KTI-1135 In Progress
Motivation: I'm going to drop NonPrivateCallableAdded (KT-62655) in the
next commits. But I don't want to change the existing logic when I drop
it. That's why I have to introduce the "Unknown" case
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
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 is IDE quick fix which suggests to copy mismatched annotation
from `expect` to `actual` (see KTIJ-26633). It needs to find
`actual` PsiElement where to add annotation. Before previous commit, it
was easy - just get source of `Incompatibility.actualSymbol`.
After previous commit, the problem might be in value parameter, while
`actualSymbol` would contain function symbol. This is solved by adding
new field `Incompatibility.actualAnnotationTargetElement`.
`SourceElementMarker` introduced, because it's needed to be used in
abstract checker. Existing `DeclarationSymbolMarker` doesn't fit
because in next PR for this issue annotations set on types will be reported,
and types are not declarations.
^KT-60671
Rename to "expect" and "actual" annotation.
This will be needed in next commit to make it clear that
only expect annotation value needs special handling.
^KTIJ-26700
It was reported because in composite module analysis we have both expect
and actual annotation descriptors, which may differ.
This may lead to bugs in the checker of ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT
diagnostic.
`fqName` comparison can be safely removed, because we already check
types in `areCompatibleExpectActualTypes`.
Tests:
- typealiasedAnnotation.kt - for annotation use (so it has different
ClassId)
- typealiasedAnnotationAsArgument.kt - when typealiased annotation
used in another annotation as argument
- sourceRetentionAnnotationsWhenTypealias.kt - tests same as
compiler/testData/diagnostics/tests/multiplatform/annotationMatching/sourceRetentionAnnotationsWhenTypealias.kt
No special test added for opt-in, because it's prohibited to have
expect/actual opt-ins by EXPECT_ACTUAL_OPT_IN_ANNOTATION checker.
^KTIJ-26700
In the following scenario, when we search corresponding expect member
for actual `A.B`, we can skip checking compatibility of `B` scope.
```
class A {
class B {
fun foo() {}
}
}
actual typealias AImpl = A
```
This is because:
1. Annotation checker runs no matter if found expect class is compatible
or not.
2. Class always has at most one corresponding `expect` class (unlike for
functions, which may have several overrides), so we are sure that we
found the right member.
^KT-60668
^KT-60936
Will be needed in subsequent commits for the annotation checker.
`findExpectForActual` is not suitable for the checker because
`findExpectForActual` searches expect class with same `ClassId` for
actual class containing current member (see method
`findClassifiersFromModule`), which is:
1. Unnecessary, since we already have expect class in annotation checker
2. Incorrect when class actualized via typealias and `ClassId` is
different.
So, it is needed to extract logic of searching potential expects
for actual member and already known expect class.
^KT-60668
^KT-60936
This reverts commit 529a1dd720.
This commit was needed to workaround broken incremental compilation in
JPS in Kotlin plugin. The incremental compilation bug is reported
KT-60759
As promised in 529a1dd720, after a few
days in `master` I revert it
Review: https://jetbrains.team/p/kt/reviews/11724/timeline
^KT-61163 Fixed
Review: https://jetbrains.team/p/kt/reviews/11599/timeline
They can be safely skiped because we check overridden descriptors
anyway.
IMO, it's a bug that delegated descriptors are copied with default
params. But it's much harder problem, and my IMO can easily be wrong for
some weird reason.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
Motivation:
- Functions with prefix "are" must return Boolean. And
AbstractExpectActualCompatibilityChecker even already contains some
functions with prefix "are" that return Boolean (e.g.
`areCompatibleCallableVisibilities`,
`areCompatibleSupertypesOneByOne`, etc)
- Unification with functions that are prefixed with "are" and return
Boolean
This is needed to workaround broken incremental compilation in JPS in
Kotlin plugin. The incremental compilation bug is reported KT-60759
In Kotlin plugin I created the same commit which changes the name of the
function on the call-site.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
After a few days in master branch, I will revert this commit
^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
Currently, property `hasSourceAnnotationsErased` returns the opposite
to what is stated in name. Invert it both in implementation and on
call site.
^KT-58551
Many errors are reported in stdlib with these annotations
(SinceKotlin, Deprecated, so on).
But having them only on expect is a valid case. E.g. SinceKotlin added
if some old platform-specific API becomes commonized.
^KT-58551
This implementation only checks annotations set on expect/actual
declarations and requires further refinement (e.g. checking of other
annotation targets, class scopes within typealiases).
^KT-58551
Also use TypeSystemContext instead of TypeSystemInferenceExtensionContext
in AbstractExpectActualCompatibilityChecker
This is needed to have an ability to implement ExpectActualMatchingContext
for IR backend. IrTypeSystemContext may operate with type substitutors,
but there is no sense to implement all methods from TypeSystemInferenceExtensionContext
in it
In K1 .isFun is always false for Java classes, so extra check
is added for that. This is not needed for K2, because .isFun is
true for all Java classes. Here it is not necessary to check
that interface has only one method, because such check will be
done in the place where interface implementation is created.
^KT-39362 Fixed
After this commit we:
- preserve Enum.entries synthetic property in tower even in case the bound feature is OFF
- report an error on Enum.entries call in specific checker if the feature is OFF
- give this synthetic property lower priority, no matter feature ON or OFF
#KT-55251 Fixed
Denis.Zharkov