3aa84906 changed native metadata serialization to use proper platform
session, but it caused a new bug: FirKLibSerializerExtension uses
FirProvider from the passed session to get a containing file of
serialized declaration to put some extension into the metadata. And
platform session doesn't contain information about any declarations
except platform ones
So it's needed to use the proper FirProvider in it, which can be
extracted from Fir2IrComponents. This provider contains providers from
all sessions that are being compiled plus providers for top-level
declarations generated by compiler plugins
^KT-65024 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
For per-file caches the data race is still there, but since per-file caches are
only used for incremental compilation, it's ok to leave it as is for now (we cope
with the data race by using a separate folder for each Gradle task).
This is already the case for Kotlin/JS.
This is required for fixing KT-63670: `linkViaSignatures` implies that
`SymbolTable` is used in FIR2IR, and in case if two declarations
have the same `IdSignature`, we have a crash in FIR2IR:
exception: java.lang.IllegalStateException: IR declaration with
signature "/foo|foo(){}[0]" found in SymbolTable and not found in
declaration storage
If we're not using SymbolTable, FIR2IR finishes successfully, and we can
safely proceed to the KLIB serialization stage, at which point we
can show the user a diagnostic about clashing signatures.
Since we've disabled SymbolTable, we also needed to fix the logic that
relied on its presence. Fortunately, such logic only includes
filtering out unused libraries. Instead of iterating over symbols in
SymbolTable, we iterate over cached symbols in Fir2IrDeclarationStorage
and Fir2IrClassifierStorage, which seems to do the trick just as well.
While not beeing final solution, this is closer to what
we want to have in the end. Enabling on non-JVM targets
would help better testing.
Enabling in JVM is now not possible yet, as some of the bugs are
not fixed yet (check KT-61360 for details)
^KT-62476
Vladimir Sukharev