Otherwise there's a chance the other trap file we're relying upon to populate the files table on our behalf gets overwritten (e.g. superceded by a newer .class file or more appropriate extractor) and we end up with a dangling reference.
This adds only populating the tables when the label is new, to avoid emitting files entries every single time a generic class specialisation is mentioned.
This is because different instances might see the code in different locations (e.g., the class file exists in more than one jar) or with no location (seen as a .java file passed to kotlinc).
While I'm there, improve the order of checks and fix a trivial bug in withFileOfClass
This affects the trap labels for methods, and therefore consistency with the Java extractor.
TODO: check whether we can unify `erase` and `toRawType` entirely.
Previously by using major version 0 to represent the no-virtual-file case these got highest priority. This meant that a class extracted relating to a .java file seen by the Kotlin compiler, which necessarily lacks a useful source-location, was highest priority. Now that should get overwritten whenever anybody sees it in the form of a .class
file, since this will have version information.
This should in particular eliminate the case where a generic class is extracted with no useful source location (based on .java source), then generic instances are extracted with a useful source location (based on a .class source), but the location isn't in the database.
These use compiler-internal intrinsics at the IR layer, which are later lowered to java.util.Arrays calls. This performs that lowering in the same manner.
Fixes:
[TYPES_NOT_DISJOINT] Base types @class and @interface are not disjoint. A common value is 225832
Relevant element: id=225832
Full ID for 225832: @"class;kotlin.internal.LowPriorityInOverloadResolution"
when Kotlin and Java both see such a class.
Big arity lambda calls in IR look like standard method calls to an `invoke` with N arguments. However, this method doesn't exist in JVM, so instead we need to extract a call to `FunctionN.invoke(Object[])`.
Otherwise when the init block is followed by other constructor statements we can get a gap in a BasicBlock's child sequence due to the child init block never getting created at all.
