This showed up as a bug in Kotlin 2 mode:
We were starting with the Class Id "java/util/Map.Entry", which we then
converted to the FqName "java.util.Map.Entry", and then back to a
Class Id with ClassId.topLevel. This gave us a Class Id that
referenceClass wasn't able to resolve.
Now we just stick with the Class Id that we started with, and the class
can be resolved by Kotlin 2.
In some cases, we were writing diagnostics to TRAP files where they
shouldn't be written. Such TRAP files don't define #compilation, so TRAP
import gave errors.
Now we use DiagnosticTrapWriter to get the type system to check that we
are writing diagnostics to the right place.
This will allow the extractor to emit class(id, ...) when all it knows about a class is its name, due to not having it available on the classpath. Previously it would have had to guess whether it belonged to @class or @interface, possibly introducing an inconsistency.
The build no longer works for Kotlin < 1.8: We get
error: class 'org.jetbrains.kotlin.ir.IrElement' was compiled
with an incompatible version of Kotlin. The binary version
of its metadata is 1.8.0, expected version is 1.6.0.
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.
This fixes two mistakes: return-type extraction not imposing a wildcard where a Java prototype explicitly uses one, and nested wildcard detection quietly failing due to not looking through a `JavaWildcardType` correctly.
I add a variant of the `kotlin_java_lowering_wildcards` test where Java prototypes are only seen from Kotlin, to be sure extraction is working as expected.
For example, Java code might use `HasOutVariance<? extends String>`, or `HasInVariance<? super Object>`, both of which are needless wildcards and which the Kotlin extractor would previously have refused to reintroduce due to their not specifying a larger type than their bound. However this led to inconsistency with Java extraction, which
extracts the type as it appears in source.
This seems to particularly happen with generated code, e.g. the output of the Kotlin protobuf compiler.
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.
