This commit is intended to get a more clear diagnostic in case when
the type checker creates an inconsistent error type due to some
classifier inaccessibility. Before this commit, we reported simply
ARGUMENT_TYPE_MISMATCH (see test). Now we report also
MISSING_DEPENDENCY_CLASS by analyzing an error type of a qualified
expression.
#KT-66356 Fixed
Otherwise, we can get in a situation where the single item is flexible,
and we replace its attributes with the attribute of the lower bound,
which messes up `EnhancedTypeForWarningAttribute`.
#KT-65193 Fixed
Affected test data was in a correct state in the corresponding MR branch, but that state was invalidated by the appearance of 9d566465 in the master branch. Because the MR branch in question was created and checked via CI runs before 9d566465 was committed to master, the discrepancy couldn't be caught by MR quality gates.
It's caused by checking the return type of an inherited property.
toConeKotlinTypeProbablyFlexible() returns an error type when the
type ref is unresolved instead of throwing.
This "breaks" some override checks and in the added test, it leads
to an additional candidate being created for a synthetic property.
However, the candidate has applicability K2_SYNTHETIC_RESOLVED
and gets filtered out because the real property has a higher
applicability.
#KT-66392 Fixed
This commit improves four aspects of WRONG_JS_INTEROP_TYPE error reporting:
1) more precise source code ranges are preferred when possible (e.g. value parameter type instead of the entire value parameter, explicit return type instead of the entire declaration, etc.)
2) only relevant parameter and return types of function types are reported as wrong (to prevent confusion with the "function types are supported" part of the error message)
3) WRONG_JS_INTEROP_TYPE errors are now deduplicated in cases where more than one such error was previously reported because of compiler-generated declarations
4) error messages were slightly proofread and contain slightly more information now
This commit in fact changes two very related places:
- first, it implements forgotten 'enhancedForWarnings' in K2 enhancement
- second, it repeats KT-48515 fix for K2 while enhancing wildcards
#KT-65594 Fixed
Related to KT-48515, KT-63746
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
Dmitriy Novozhilov