Previously we used the IrDeclaration itself, but in Kotlin 1.7 this can be ambiguous because we can get more than one copy of a class in different modules.
I'm not sure how these looked in 1.6 and below yet, but in 1.7 they appear with visibility = public, but a descriptor field set to indicate they have a name clash with a 'real' function.
- Implement getIrStubFromDescriptor for Kotlin 1.7
- Stop using ClassSymbol.signature, which is now only populated for classes built from Kotlin, and noteworthily is null for primitive and other internally-synthesised types.
The QL library already expects these to be missing in some cases and generates its own names when they are absent. Writing synthetic names to the database can produce inconsistencies if the true name is seen later.
For example, 1.7.0-RC would previously be truncated to 1.7.0 resulting in failure to build the single-version distro as all candidate alternate-version kotlin files would be ignored.
Kotlin permits introducing a `? extends ...` wildcard against an Array even though the class is final, so long as its argument itself can be extended (i.e. isn't final or is another array type satisfying this condition).
Contravariant arrays get lowered to Object[], and are subject to automatic `extends` wildcard introduction, unless their element type was already Any.
This should lead to better Java/Kotlin correspondence since the Java extractor will naturally name trap files for JVM names, and avoids a specific bug (tested) where MapsKt.iterator's two overloads (one taking `Map` and one `MutableMap`) are JvmName'd differently since their Java-lowered signatures would be identical. Without this change only
one of the iterator overloads would get extracted leaving the other one a dangling reference.
The Kotlin authors changed this to avoid a clash on List<Int>, but we must reverse the renaming so the Kotlin and Java views of the same class file extract alike.
Previously we handled the case of *methods* with potentially-wildcarded types that Java nontheless constrains to be invariant, but missed out the constructor case.
For Java classes this means following the structure of the underlying Java type to determine where the wildcard was really present and where the Java signature ruled it out. The annotation tracking simply means looking for @JvmSuppressWildcards on any surrounding class or function to turn off wildcard introduction by default.
The Kotlin compiler represents types like List<out CharSequence> internally as List<CharSequence> due to the fact that List's type parameter is covariant, and similarly Comparable<in CharSequence> where Comparable's type parameter is contravariant. However it restores use-site variance when emitting class files, so we must do the same thing for
compatability with Java code.
Note this is a partial solution because it will also add wildcards to Java .class files that *could* have a variance / wildcard but don't -- for example, a Java method could really take an invariant Comparable<CharSequence>, which is only achievable in Kotlin via the @JvmSuppressWildcards annotation. We also don't yet support
@JvmSuppressWildcards given on a surrounding class or function.
