There was a bug in the DFS. Whenever we encountered a "requires
transitive X" directive in some module, we recursively invoked DFS not
on X but on `dependencyName`, which is the target module that we're
trying to find the path to. And that always failed, because no module
requires itself.
#KT-66275 Fixed
If a potential receiver is resolved to an error type, we consider
any other type as a subtype of it and therefore may select
any candidate that we happen to find in a scope.
In particular, in the case of scripts, or code with a context receiver,
the receiver candidate resolved to a cycle was accepted as a receiver
to an invoke on a random class from stdlib.
The fix skips adding invoke resolve task in this case, allowing
the tower to find the correct candidate in another scope.
#KT-64241 fixed
#KT-65576 fixed
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
Iaroslav Postovalov