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.
