This change is required to fix stdlib compilation with enabled
linking via signature. All primitive iterators are considered to be
builtins and are created during compile time as deserialized
declarations (at least in K1). But if we meet the definition of some
primitive iterator in code, for example, during stdlib compilation,
we will end up with two different descriptors (deserialized and lazy)
that describe the same entity. Because of that we have conflicts in
symbol table:
* For descriptors, we will end up with multiple IR declarations
that describe the same class, but with different descriptors. With
some magic compilation still works.
* For signatures, we will end up with only one IR declaration in the
table, but it will have wrong deserialized (instead of lazy)
descriptor.
In the end, this change allows us to initialize iterators in advance
with correct descriptor.
#KT-56230
Let ConeCompositeConflictResolver pass the results of the previous
resolver to the next one.
Otherwise, we get false positive conflicts when a set of candidates
can't be fully reduced by one resolver but could be resolved by the
subsequent application of multiple ones.
This change makes ConeCompositeConflictResolver order-dependent and
thus, ConeOverloadConflictResolver must be invoked last, because it
must work on a pre-filtered list.
Also, let ConeEquivalentCallConflictResolver use
FirStandardOverrideChecker instead of compareCallsByUsedArguments
because it's stricter.
This all fixes a false positive overload resolution ambiguity in common
metadata compilation that is caused by stdlib using the new KMP
format.
Now stdlib metadata is in the classpath, and so declarations from the
stdlib are returned from both MetadataSymbolProvider and
KlibBasedSymbolProvider.
This isn't a problem per se because duplicate candidates are filtered
out by ConeEquivalentCallConflictResolver (K1 works analogously), but
in the case of top-level functions with generic receivers like
Collection<T>.toTypedArray, the check failed because of the direct
comparison of receiver types.
#KT-60943 Fixed
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
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
For StrongIncompatible `actual` declaration is considered as overload
and error reports on expected declaration. For WeakIncompatible the
error is reported straight away
Before the refactoring `areCompatibleClassScopes` returned just
`Incompatible`. It is bad because StrongIncompatible isn't possible for
classes (classes can't be overloaded). Now all class incompatibilities
are weak.
The commit has a minor impact on observable behavior (cases where we
reported the compilation problems are still reported but on another
elements):
- We no longer report type parameter class incompatibilities on expect
declaration, we report them only on actuals (it happened because all
WeakIncompatible are reported only on actuals)
- In a sense, Java implicit actualization was the only way to "overload"
classes (it would be a redeclaration compilation problem, so it
doesn't count as a valid "overload"). And since type parameters
incompatibility was StrongIncompatible for classes, we counted them as
"overloads" and didn't report incompatibility problems on Kotlin
class. Now we do report. (see
implicitJavaActualization_multipleActuals)
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
Extract main logic of `areCompatibleCallables` into two functions:
`areStrongIncompatibleCallables` and `areWeakIncompatibleCallables`.
The main point is that `areStrongIncompatibleCallables` &
`areWeakIncompatibleCallables` have very specific return types.
This commit doesn't change any logic. The commit makes the API more
type-safe ensuring that bugs like in previous commit (KT-60902) won't
happen again
^KT-60902 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
We should prioritize to return STRONG incompatibilities over WEAK
incompatibilities. But this invariant broke in `areCompatibleCallables`,
because `areCompatibleTypeParameters` returns incompatibilities of both
types, and `areCompatibleTypeParameters` is called in WEAK
incompatibilities section.
The fix is to split `areCompatibleTypeParameters` into two functions:
`areStrongIncompatibleTypeParameters` and
`areWeakIncompatibleTypeParameters`. And call each of this function in
appropriate `areCompatibleCallables` sections.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
This is a preparation refactoring for the following KT-60902 fix and
type-safety refactoring.
This commit doesn't have observable side effects (and can be called pure refactoring) because the following conditions:
1. `expectDeclaration is ConstructorSymbolMarker && actualDeclaration is ConstructorSymbolMarker`
2. `expectDeclaration is FunctionSymbolMarker != actualDeclaration is FunctionSymbolMarker`
can't be both `true` at the same time
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)
This is needed because after changing default language version to 2.0,
we still need to test many scenarios from this test in K1.
Move K1-specific tests to OldCompileKotlinAgainstCustomBinariesTest, and
K2-specific tests to FirCompileKotlinAgainstCustomBinariesTest.
Mute failing K2 tests via `muteForK2`. It will throw exception if the
muted test will suddenly start passing.
This test uses multiple features which are obsolete and will be
discontinued soon:
- Language version 1.4
- Expect/actual declarations in the same module
- Declaring inline classes via "inline class"
Check that the client code compiles against the "broken" classpath
instead. Descriptor text dump is a part of the obsolete test
infrastructure and should not be used anymore.
`DelegatingConstructorCall` -
because in this case there is
either `UNRESOLVED_REFERENCE` or
`SYNTAX` already.
`ErrorTypeRef` - because in this
case there is `SYNTAX` already.
Note that there is only 1 test
that shows this behavior, and
it's LT-specific. It's
`FirLightTreeOldFrontendDiagnosticsTestGenerated.testKt847`, and
in this test the string template
is parsed and processed
differently in LT and PSI:
- in LT there are 6 nodes: "",
"$this", " must be", "$as", "$t",
"".
- in PSI there 4 notes: "$this",
" must be", "$as", "$t".
We should copy `-Xcontext-receivers` flag from the original arguments
during the setup of compiler arguments in the FP test
Otherwise, UNSUPPORTED_CONTEXTUAL_DECLARATION_CALL diagnostic gets
triggered where it shouldn't be present
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
Without this change, the Unit type does not have Any members declared
in its scope which breaks the expect/actual mapping
(aka we cannot find actual `toString` for expect one).
Ivan Kylchik