A type alias may still be inherited from. For example:
```
sealed class MyClass
typealias T = MyClass
class Inheritor : T() // `Inheritor` is a direct inheritor of `MyClass`.
```
The index is a simplified version of the IDE's
`KotlinTypeAliasByExpansionShortNameIndex`, but it should be sufficient
for virtually all cases.
^KT-66013
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
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
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.
The purpose of this class was to avoid reporting conflicting JVM
signatures / accidental override errors when there's a similar (e.g.
conflicting overloads) diagnostic already reported.
It was not used meaningfully because it only affected diagnostics
reported by the old JVM backend. Also, in real life, backend diagnostics
would not be reported anyway in most cases because backend is not even
run if there's an error after frontend.
There's no behavior specific for JVM backend diagnostics in any of the
affected tests, and this code is using an incorrect way to obtain those
diagnostics, so it should be removed anyway.
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
Johan Bay