^KT-63860 Fixed
Review: https://jetbrains.team/p/kt/reviews/13334/timeline
The previous code was nonsense (I wrote it). It doesn't make sense to
subtract actualOverriddenDeclarations from expectOverriddenDeclarations.
Default parameters are mentioned on the expect side. So default params
in expect/actual supertypes won't be subtracted from
expectOverriddenDeclarations (but should be)
There were a number of locals where components of InitialConstraint were
named lower and upper in the FirBuilderInferenceSession.
That is not true for equality constraints, so such naming should be
avoided to avoid misconception about the nature of type relation encoded
in constraint.
^KT-64031 Fixed
It's now impossible to add new classes to metadata, because this
functionality is not implemented in IrGeneratedDeclarationsRegistrar
and FirDeclarationsForMetadataProviderExtension is removed
`IrGeneratedDeclarationsRegistrar` assumes that all generated functions
are correct from a Kotlin point of view. But `writeSelf` method on JVM
is a static method outside any object/companion object
So to properly calculate containing class for this method we should
generate a dispatch receiver parameter, register the method in metadata,
and then remove the parameter (to make function static)
The condition was added to the substitute function, when it was also
re-used in delegate inference.
However, delegate inference no longer uses this function.
It is not very possible to both have variable fixed and being present in
nonFixedToVariablesSubstitutor in builder inference.
^KT-64028 Fixed
There are two overloads of substitute function
in the FirBuilderInferenceSession.
In fact, it has very different usage and semantics.
Relates to KT-64028
This commit covers enum entry vs companion member case,
when two companion objects are in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets two candidates with companions.
After that it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier, so no influence here.
With two ambiguous candidates with companions for Some,
OVERLOAD_RESOLUTION_AMBIGUITY is reported.
This commit covers enum entry vs companion member case,
when one companion object is in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets the only candidate with companion.
After that it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier, so no influence here.
Finally during foo resolve it should choose between enum entry and
companion member, and enum entry wins due to KT-37591.
This commit covers object vs static member case,
when no companion objects are in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets two erroneous candidates
without companions. After it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier.
That's why we finally report NONE_APPLICABLE on candidates with companions.
This commit covers object vs companion member vs static member case
but now we have two different companions (first is empty) in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets some/Some & some2/Some
because both of them have a companion. This means ambiguity.
After it tries to resolve Some as a qualifier, but we have no scope
with a single qualifier, so finally we prefer to report ambiguity
from variable access resolve.
This commit covers object vs companion member vs static member case
in situation with only one companion in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets only some2/Some
because it has a companion. Then it tries to resolve Some as a qualifier,
but here we have an ambiguity, so finally Some with companion is preferred.
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver.
See also cases (3) and (7).
In this test, things work in the similar way as in constructors case (2).
K1 resolves the explicit receiver HashMap<String, String>()
to kotlin.collections.HashMap /* = java.util.HashMap */.
K2 does the similar, but fun processConstructors from ConstructorProcessing.kt
makes a type alias substitution, so in fact constructor of expanded
java.util.HashMap is processed.
Pay attention that both frontends ignore some.HashMap and java.util.HashMap
due to ambiguous classifiers in explicit star importing scope.
See FirScope.processConstructorsByName in ConstructorProcessing.kt
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver, in case
it's used as a receiver itself (::class counts as a selector equivalent).
In both these situations, we have some.HashMap & java.util.HashMap
from explicit star importing scope, and kotlin.collections.HashMap
from implicit star importing scope after it.
K1 ignores both explicitly imported classifiers due to their ambiguity,
and then resolves to kotlin.collections.HashMap at the next level.
In contrast, K2 takes explicitly imported classifiers and
properly reports ambiguity.
In this test, both frontends resolve to fun Semaphore.
Both work this way because interface/class Semaphore classifiers are
clashed (ambiguity) and ignored.
K2 reports ambiguity for some similar cases,
but constructor resolve still ignores ambiguous classifiers when found.
(see FirScope.processConstructorsByName in ConstructorProcessing.kt)
In this test, K1 resolves to kotlin.collections.HashMap /* = java.util.HashMap */
K2 does the similar, but fun processConstructors from ConstructorProcessing.kt
makes a type alias substitution, so in fact constructor of expanded
java.util.HashMap is processed.
Pay attention that both frontends ignore some.HashMap and java.util.HashMap
due to ambiguous classifiers in explicit star importing scope.
See FirScope.processConstructorsByName in ConstructorProcessing.kt
Now there are no real unresolved imports - all imports are considered
resolved starting from the IMPORTS phase and until they are proven
otherwise in the checkers.
Because of that, some `UNRESOLVED_REFERENCE` diagnostics are gone -
in the cases when such references were actually resolved through
those unsupported imports.
The compilation of incorrect files should not be affected by this,
the checkers would still prevent the compilation of the files with
incorrect imports.
But now the references to the declarations from such imports no longer
will be highlighted as unresolved references.
Error arises from the fact that type substitution operation isn't
consistent when applied to captured types.
E.g.:
```
substitution = { A => B }
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_1>
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_2>
C<CapturedType(out B)_1> <!:> C<CapturedType(out B)_2>
```
Relates to KT-53749
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
- Pass containingClass (helps to avoid calculations of the
containingClass in allRecursivelyOverriddenDeclarationsIncludingSelf
implementation)
- Reuse allRecursivelyOverriddenDeclarationsIncludingSelf by
DefaultArgumentsInExpectActualizedByFakeOverride &
ActualFunctionWithDefaultParameters
Review: https://jetbrains.team/p/kt/reviews/13244
Review: https://jetbrains.team/p/kt/reviews/13244
Motivation:
```
// Module :lib
class Foo {
val member: Int = 2
}
// Module :app
// dependencies { implementation(project(":lib")) }
class Foo {
val member: Int = 2
}
```
Before the commit:
app_Foo.expectForActual is `null`
app_Foo.member.expectForActual = lib_foo.member
After the commit:
app_Foo.expectForActual is `null`
app_Foo.member.expectForActual is `null`
If I don't fix this problem then
`CommonizerHierarchicalIT.testCommonizeHierarchicallyMultiModule`
becomes red after I fix KT-59887 in the following commits
`app_Foo.member.expectForActual = lib_foo.member` happens because we
also need to match fake-overrides (KT-63550)
I didn't measure it, but theoretically, this commit should be a
performance improvement, becuase we reuse `expectForActual` cache
Additionally, The commit breaks some other tests (e.g.
compiler/testData/diagnostics/tests/multiplatform/headerClass/actualMissing.fir.kt).
The tests will become green again, once I fix KT-59887
Review: https://jetbrains.team/p/kt/reviews/13244
Motivation: Performance. When I fix KT-59887 in later commits, I will
make actual-to-expect resolve to work not only for actual declarations.
Considering that LLFirExpectActualMatcherLazyResolver worked even for
non-KMP projects that might be a potential performance regression
FirExpectActualMatcherProcessor in the compiler does the same thing (it
checks for MultiPlatformProjects before running the transformer)
Motivation: If I don't fix it then I will get a false positive
ACTUAL_MISSING in
DiagnosticCompilerTestFE10TestdataTestGenerated.Tests.Multiplatform.Enum.testSimpleEnum
after I fix KT-59887
The commit also fixes false positive diagnostic in
annotationArgTypeAliasWithArray.fir.kt test
Review: https://jetbrains.team/p/kt/reviews/13244
Nikita Bobko