It is safe to rebind returnTarget to the original declaration during
psi2fir as it doesn't affect the resolution. We already have the same
logic for regular functions/property accessors.
This change is crucial in the context of parallel implicit type
resolution because it affects CFG builder in a bad way in the case
of on-air resolution
^KT-56551
The issue appeared when we analyzed some typealias.
1. The typealias itself could be valid, but it could point
to an invalid type.
2. The typealias could point, for example, to an unsigned
type that must be handled in a special way
#KT-59894
- Lincheck is compiled with JDK 11 and the `low-level-api-fir` module is
based on the JDK 8 toolchain, so we need to add a new module with a
JDK 11 toolchain to support Lincheck tests. We cannot bump
`low-level-api-fir` to JDK 11 because `low-level-api-fir-for-ide`
requires it to be based on a JDK 8 toolchain.
- Using a Gradle test suite is unfortunately not an option, because
`low-level-api-fir-for-ide` will think that the whole
`low-level-api-fir` module is compiled with JDK 11 if just a single
test suite has this toolchain.
^KT-62136
^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)
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.
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)
Use test compiler runner to compile JS libraries. Determine compiler
by the specified TARGET_PLATFORM. Add tests for dynamic type and
JS-specific .proto extensions.
Refactor the code for mock library compilation to make the switch
between platforms more straightforward.
KTIJ-27566
KT-63217
Note on .kjsm library symbol providers.
It's not clear whether the provider is necessary for K2 IDE and whether
there will be libraries with .kjsm files that we are going to support.
Since there are no tests that can prove the correct work of the symbol
provider right now, it's better add them later if needed.
The existing tests cover only .knm files.
KTIJ-27566
- Old backend support is not needed in `KtFe10CompilerFacility` anymore,
because it has been removed for the bytecode tool window, which was
the only user. The old backend is slated to be removed entirely.
^KTIJ-24522
We can omit `get` call to delegated property and inline
constant value directly. If we are not going to
do that, we can get a runtime exception because
all usages of const property will be inlined and the property
itself will be dropped.
#KT-63567 Fixed
#KT-63580 Fixed
When fixing KT-22004, the analysis was incomplete, the details are
available at KT-63540. This change restricts the ignore of conflicting
overloads on hidden callables only for final ones.
^KT-63540 Fixed
Previously, because we didn't handle flexible types properly in
prepareCapturedType, projections inside flexible types would only be
captured during subtyping with captureStatus=FOR_SUBTYPING
which would lead to the constraint type being wrongly approximated
(see ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint).
Fixing the capturing produced two kinds of false positive diagnostics:
1. In ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint we would get two instances of cone types
that are structurally equal and containing the same captured type.
However, because we only skipped subtyping if the types were
referentially equal, we would get a contradiction here.
The fix was to use structural equality instead, which should be okay
as the captured type instances are the same.
2. Reified type variables were inferred to captured types because
flexible arrays with captured upper bounds
(Array<Foo>..Array<Captured(out Foo)>?) were not properly approximated.
#KT-62609 Fixed
Tomas Husak