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
Previously the addresses were resolved by only respecting
CallableId or ClassId. This however, could lead to
resolving symbols that were not defined in the klib which
initially provided the declaration address.
E.g. this commit adds a test in `GetSymbolsTest`, where
```
// A.kt
private fun foo() = 42
// B.kt
private fun foo() = 42
```
In this case the two source files (A.kt and B.kt) defined
two distinct addresses for `foo`. However: Resolving
any of those two addresses would resolve both functions (A&B), which
is not expected.
^KT-66271 Fixed
This `klibSourceFile` information is deserialized from klibs
to retain the information of the original SourceFile location
of a declaration.
^KT-66271 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.
This should protect from cases when CompositeMetadataArtifact got
polluted due to some bugs or user misconfiguration.
One of the cases is when resource file is added to common source set.
In this case due to KT-66563 bug, resources will be mixed in to the
KLIB content. But if for some source set there is no sources.
Then in composite metadata artifact will be only the resources.
And previous implementation of CompositeMetadataArtifactImpl treated
that content as Metadata KLIB, however the metadata compiler didn't.
And thus it was failing with. This change makes it stricter.
Now it checks for `default/manifest` entry. This entry is considered
a sane check for KLIB content.
^KT-65315 Verification Pending
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
Igor Yakovlev