This replicates an oddity in the Java extractor that it doesn't differentiate a specialisation Generic<T1, T2, ...> from the unbound type, if T1, T2, ... are Generic's declared type variables occurring in the same order. For example, in `class MyList<T> { void addAll(MyList<T> param) { ... } }`, the type of `param` is an instantiated type, but
gets extracted as an unbound type. This commit can be reverted (except for the improvement to isUnspecialised) if/when that is fixed.
(Otherwise we'll think that 1.6.10 comes before 1.6.9, for example.) This now implements the desired test: pick a version that exactly matches major and minor versions and which is the least patchlevel that is >= the target compiler.
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��
