I can't reproduce the exact circumstances, but these sometimes get "<anonymous parameter X>" names and sometimes get "$noName_X" names. Whichever way, avoiding extracting a synthetic name seems safest; anyone finding the .class file and not reading the metadata indicating it came from a `_` will extract the binary name selected, or else QL will
invent a name.
Previously these would get extracted unlike other private methods even if the class was a standard library or other external class. This could cause inconsistencies because if we also compiled the class from source we could end up deciding different names for the property's setter: setXyz$private when seen from source, and setXyz without a
suffix when seen as an external .class file. Avoiding extracting these functions from the external perspective both restores consistency with other kinds of method and avoids these consistency problems.
This makes non-companion object methods into static methods, and for companion objects introduces static proxy methods that call the companion instance method.
Note this doesn't quite implement what kotlinc does, since it will also eliminate getters and setters by promoting an object field into a static field, but our translation is simpler and only differs in private members' details.
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.
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.
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.
