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.
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.
