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.
We need to capture output for some commands we run during the build,
but this ended up being refactored so that we ate the output for all
commands. This means that we don't see warnings from the compiler.
Now we not only show the output, but we also print what commands we are
running.
We were getting:
$ echo foo > bar
$ jar -c -f baz.jar bar
-f : no such file or directory
baz.jar : no such file or directory
K-*��ϳR0�3��r.JM,IM�u�MEX��)h8������y�xk�r�rPYJO�?y_wTbarK���P�e2`wT META-INF/�`wTYJO�??=META-INF/MANIFEST.My_wT�e2~�barPK��
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.
