These should be handled the same as regular methods: extract type accesses for parameters and methods only if we're extracting "from source", i.e. at some point we're descended from extractFileContents.
Previously we extracted them whenever something was non-external, but this led to re-extraction when an instance of a generic type defined in source was extracted multiple times.
This is both consistent with the Java extractor's behaviour, and prevents us from trying to refer to anonymous types (e.g. anonymous objects that directly initialize properties) out of scope.
This allows the particular case of Collection.toArray(IntFunction<T>) to match, since both Java and Kotlin functions take an IntFunction<T> but they use different function-local type variables.
This would also allow toArray(Array<T>) to work similarly.
This didn't appear to be necessary because the Kotlin and Java versions of Map (for example) are designed to be compatible, but in certain cases their functions have the same erasure but not the same type (e.g. Map.getOrDefault(K, V) vs. Map.getOrDefault(Object, V).
These have different erasures which was leading to callable-binding inconsistencies.
These include Collection.size() for example, which has a Kotlin property called `size` but whose getter is not named `getSize()`.
These would normally be accounted for using `@JvmName`, but some core methods are lowered by a special compiler pass instead.
(As before, these are not really unspecialised, they are instantiated by their own type parameters, but this replicates the behaviour of the Java extractor)
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.
