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
klibs provide information about the container source file
in the KlibMetadataProtoBuf extensions for functions,
properties and classes.
This information is deserialized and attached to the
`klibSourceFile` extension (stored in FirDeclarationDataRegistry)
^KT-66271 Fixed
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
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
FirNamedArgumentExpressions don't exist anymore during FIR2IR phase
and so handling FirSpreadArgumentExpression in Fir2IrVisitor is
sufficient.
#KT-66124
Kirill Rakhman