There is a thing that `CandidateCollector` adds error candidate to the
list of resulting candidates only if its applicability at least the
same as current applicability of the collector
Also there is a problem, that deserialized symbol provider in CLI compiler
and stub-based symbol provider in AA may return the same declarations
in different order. This provokes the difference in the resulting set
of candidates between the two modes:
```
val x by unresolved
```
During the resolution of this code compiler tries to find function `getValue`,
and there are 6 of them in the stdlib. From them we are interseted in
specific three:
1. `fun <K, V> Map<K, V>.getValue(key: R|K|): R|V|`
2. `inline operator fun <V, V1 : V> Map<in String, @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
3. `inline operator fun <V, V1 : V> MutableMap<in String, out @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
- (1) is inapplicable with `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
- (2) and (3) are inapplicable with `INAPPLICABLE_WRONG_RECEIVER`
- `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR` is more specific applicability than `INAPPLICABLE_WRONG_RECEIVER`
- CLI compiler always sees those functions in order 1 -> 2 -> 3
- AA providers sometimes returns them in order 2 -> 3 -> 1
So in CLI compilation candidates (2) and (3) are not added to the resulting
set, as they are "less applicable" than (1), but in AA compilation they
can be added to the set before (1), which causes sporadic change in
FIR dump of `unsafeAssignmentExtra.kt`
To workaround this problem it was decided to treat `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
and `INAPPLICABLE_WRONG_RECEIVER` applicabilities as "equally specific"
^KT-65218 Fixed
There's a separate test data directory `testsWithJvmBackend` with a
runner that properly invokes the JVM backend and reports diagnostics
from it. All tests where JVM diagnostic presence/absence is important
were copied/moved there in this and previous commits.
The problem with the code removed in this commit is that it invoked some
parts of the _old JVM backend_ and old light classes, which is very far
from what users see in the production compiler at this point. This led
to real issues where we implemented incorrect behavior in K2 based on
the misleading diagnostic report from the K1 test.
The diagnostic in `triangleWithFlexibleTypeAndSubstitution4.kt` was
removed, but there's a copy of this test in `codegen/box/javaInterop`
which fails for K2 (KT-66529).
The diagnostic in `intersectionWithMappedSignature.kt` was removed and
that is OK because at this point CONFLICTING_JVM_DECLARATIONS there
seems like a bug in the old JVM backend.
In fact the latest compiler (neither K1 nor K2) does NOT report an error
here, see KT-66522. The error was there in the diagnostic test because
the test used custom code which invoked parts of the old JVM backend to
report signature clash errors.
The issue is rather minor and is present since 1.5, so to reduce
confusion, the test is deleted.
#KT-66522
In this commit, tests where backend diagnostics were reported correctly
are being moved.
FirScopeDumpHandler was added to FIR diagnostic tests with JVM backend
to support `SCOPE_DUMP` in `overridesBuiltinNoMagic.kt` and
`charAtAndOverload.kt`.
This is basically a copy of the test
`diagnostics/tests/j+k/primitiveOverrides/triangleWithFlexibleTypeAndSubstitution4.kt`.
The diagnostic version of the test is not removed because it has
frontend-specific diagnostics `FIR_DUMP` and `SCOPE_DUMP`.
This test is copied to make it clear that it actually passes in K1, and
new errors in K2 here are technically a breaking change, see KT-66529.
The error CONFLICTING_INHERITED_JVM_DECLARATIONS was present there only
because diagnostic tests used parts of the old JVM backend to report JVM
backend diagnostics.
#KT-66529
- `typeParameterWithTwoBounds.kt` is already present in
`diagnostics/testsWithJvmBackend/duplicateJvmSignature/erasure/`.
- `clashWithCompanionObjectField.kt` is already present in
`codegen/box/fieldRename/jvmFieldNoClash1.kt`.
- `jvmFieldAndJavaGetter.kt` is already present in
`codegen/box/jvmField/noClashWithInheritedJavaMethod.kt`.
In case of two latter tests on JvmField, there's (correctly) no error
reported in JVM IR, which is why those are box tests.
Resolve it like a receiver of a call.
This makes the resolution result consistent with the equivalent
function call.
The K1 difference is covered by KT-66453.
#KT-66504 Fixed
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Instead, it should happen during BODY_RESOLVE phase.
This fixes KT-66150. The problem was, that `super<B>.f()` expression
in delegated constructor call was transformed during TYPES phase,
and type transformer has no special logic for allowing bare types in
super qualifiers, like the one in expressions transformer (see
`org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer.transformSuperReceiver`).
As a result, `B` without type argument leads to
WrongNumberOfTypeArgumentsError.
It looks incorrect that expressions in constructor call resolved
during TYPES phase, so skipping transformation of
argument list seems like the best solution here.
^KT-66150 Fixed
In most affected tests, the backend diagnostic such as "conflicting JVM
signature" or "accidental override" is directly caused by some already
existing error reported by frontend, so it doesn't make sense to check
backend diagnostics there.
Tests where that was not the case were moved/copied to
`testsWithJvmBackend`.
All of these tests were actually copied to `testsWithJvmBackend` in
866f188120, but it's unclear why they were copied instead of moved. The
test runner for `testsWithJvmBackend` correctly runs the compiler
pipeline and obtains errors reported by the backend, as opposed to the
common diagnostic tests which have a very custom code, using parts of
the old JVM backend, to obtain these diagnostics.
- `require.kt` was added to check JVM accidental override diagnostic
when using the "traits with required classes" feature, which was
removed a long time ago.
- `withErrorTypes.kt` was testing conflicting JVM declarations error (a
backend diagnostic) in presence of error types -- not very useful
scenario because the backend is not run when there's a frontend error.
Basically, just calculate them the same
way it's done for other members.
`chooseIntersectionVisibilityForSymbolsOrNull`
is named like this to prevent a JVM clash.
^KT-66046 Fixed
Dmitriy Novozhilov