Currently, REDECLARATION is not reported if two conflicting declarations
are in different source sets (KT-59898). However, when it's fixed,
we want this test to keep testing the signature clash diagnostic,
and not fail because of unexpected REDECLARATION error.
For some reason type parameters end up in
`GlobdalDeclarationTable`, and thus we tracked them in
`IdSignatureClashDetector`, which wasn't right and confused the
diagnostic renderer that uses
`org.jetbrains.kotlin.resolve.MemberComparator` for sorting the
declarations to display in diagnostics. That comparator doesn't know
jow to work with type parameters.
Besides, type parameters, like many other types of declarations, are not
considered public wrt KLIB ABI, so there's no need to show
CONFLICTING_KLIB_SIGNATURES_ERROR for them.
^KT-65723 Fixed
Show what kind of declarations exactly are clashing: functions,
properties, or fields.
This is so that diagnostics about clashing properties and fields are
distinguishable from one another, since properties and fields
are rendered the same way in those diagnostics:
The issue was that when rendering declarations in
the `CONFLICTING_KLIB_SIGNATURES_DATA` diagnostics, we sort them using
`MemberComparator`. That comparator falls back to comparing
declarations' renders if all previous checks were unsuccessful
(and in case of almost identical properties they are). The renderer that
the comparator uses also renders the properties' backing field
annotations, for which it calls `PropertyDescriptor#getBackingField`.
That method wasn't implemented in IR-based descriptors.
This is fixed by returning an instance of the new
`IrBasedBackingFieldDescriptor` class from that method.
^KT-65551 Fixed
We only want to report signature clashes for declarations that come
from the module currently being serialized. In GlobalDeclarationTable,
declarations from other modules could also be stored.
Checking whether a declaration is a Lazy IR declaration to
determine if it comes from an external module works okay, but it is
a hack which relies on an implementation detail of IR, which may or
may not work in the future.
Use a more robust logic here, since IrFileSerializer is always aware
which declarations are declared in the current module and which are
just referenced from it.
If we encounter a declaration in the current module whose signature
is the same as that of a declaration in another module which we happen
to also reference from the current module, don't report any errors,
just like we don't do it in Kotlin/JVM. This leaves the user in the KLIB
hell situation, but this is intentional, because otherwise a legitimate
change like moving a declaration to another module and marking
the original one as `@Deprecated("", level = DeprecationLevel.HIDDEN)`
would lead to a error, and we don't want that.
Also, don't try to show the diagnostics on a declaration that doesn't
have an IrFile.
^KT-65063 Fixed
Now, we detect clashing signatures during serialization to KLIB and
report a compiler error if two or more declarations have the same
`IdSignature`
For example, for the following code:
```kotlin
@Deprecated("", level = DeprecationLevel.HIDDEN)
fun foo(): String = ""
fun foo(): Int = 0
```
the compiler will produce this diagnostic:
```
e: main.kt:1:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
e: main.kt:4:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
```
Note that we report this diagnostic during serialization and not earlier
(e.g., in fir2ir) for more robustness, so ensure that we check
exactly the signatures that will be written to a KLIB.
If we later introduce some annotation for customizing a declaration's
signature (e.g., for preserving binary compatibility), this
diagnostic will continue to work as expected.
^KT-63670 Fixed
Andrei Tyrin