This was testing that a signature inconsistency occurs, but this now manifests as a db inconsistency which can't be used as a test expectation because specific tuple numbers are liable to change with the environment.
These occur because the Companion field is odd, being extracted from source but not having an associated FieldDeclaration, leading to PrintAst enumerating the node differently depending on whether it has a source-file location or not but in either case choosing not to show it.
These resulted from the Java compiler exploring NotNull and other Kotlin-emitted annotations, which it no longer does because it finds a .class trap file already present and truncates its class-graph walk
There is also one non-location change: kotlin.Byte (and likely other primitives) now have real equals and toString overrides, which matches their native source and documentation; before they appeared to have fake overrides.
A bunch of test expectations change because 7f531d8426 means that we now see (a) local variable declarations with source locations covering only their identifier, not the whole statement, and (b) more SYNTHETIC_OFFSET values for the parts of a destructuring assignment
or initialiser, which show up as file.kt:0:0:0:0 in DbLocation form.
Java's regular strings are formatted as they appear in source, but we don't easily have this information available in Kotlin. During annotation extraction however it guesses a source rendering because the source is not necessarily available. By formatting to match the annotation extractor, we prepare to ensure consistency with a Java database
when extracting annotations as seen by Kotlin.
This avoids extracting the default value expression in more than one place, which causes inconsistencies for e.g. anonymous classes, which expect to have a single `new` expression associated.
In this circumstance the compiler seems to generate a specialised version of the implementing function with its argument type replaced by the interface-implementing child class' type parameter. However it stores a back-pointer to the real declared function, which we should use as the call target.
All of java.util.{Collection,List,Map} redeclare `boolean equals(Object)` in order to add documentation, as a side-effect creating a real symbol that can be used as a dispatch target.
Previously we accidentally named these something like <init>$main, which is a name-mangling the Kotlin compiler applies to internal methods but not to constructors, which look to Java just like regular public constructors.
Dataflow requires accounting for the fact that the varargs parameter isn't necessarily last in the parameter list in a couple more places. Default handling just requires that if the only null parameter is the varargs argument, and it has no default value, then no $default method is required-- the caller is expected to simply pass nothing (at QL
/ source level) or an empty array (at JVM level).
