This imprecise implementation turned out to cause linkage errors, e.g. when type variables in the signatures of member methods were inappropriately erased. For the time being we accept that $default methods despite having erased signatures in keeping with their JVM representation can contain expressions whose types make reference to their
surrounding function or class' type variables, even though they should be out of scope since $default methods are static and don't have type parameters, and need to cope with the inconsistency in QL.
These are due to changing string literal representation, omitting empty annotations blocks, and changes to how annotation classes are represented in the database.
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
We used to get alerts for the class around a local function, a lambda,
or a function reference, which we give name "". Now those are marked as
compiler-generated, and the query ignores compiler-generated types.
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.
