For Java classes this means following the structure of the underlying Java type to determine where the wildcard was really present and where the Java signature ruled it out. The annotation tracking simply means looking for @JvmSuppressWildcards on any surrounding class or function to turn off wildcard introduction by default.
The Kotlin compiler represents types like List<out CharSequence> internally as List<CharSequence> due to the fact that List's type parameter is covariant, and similarly Comparable<in CharSequence> where Comparable's type parameter is contravariant. However it restores use-site variance when emitting class files, so we must do the same thing for
compatability with Java code.
Note this is a partial solution because it will also add wildcards to Java .class files that *could* have a variance / wildcard but don't -- for example, a Java method could really take an invariant Comparable<CharSequence>, which is only achievable in Kotlin via the @JvmSuppressWildcards annotation. We also don't yet support
@JvmSuppressWildcards given on a surrounding class or function.
Specifically `const`, `lateinit` and `@JvmField` properties get a static field which belongs to the containing class not the companion object, such that Java can address them via the containing class name rather than have to navigate a companion object pointer.
Collection, List and Map all define various methods which are either made more generic in Kotlin (e.g. `remove(Object) -> remove(E)`, `containsAll(Collection<?>) -> containsAll(Collection<E>)`), or are made invariant (e.g. `addAll(Collection<? extends E>) -> addAll(Collection<E>)`). This substitutes the types back to their Java signatures,
thereby avoiding differing trap labels and duplicated methods for these types and their descendents.
Make extraction messages `warning` if code is still extracted regardless of the reported issue. Make extraction messages `error` if some code is not extracted.
For example, in implementing Producer<T> by an actual lambda of type () -> Int, the return type should be Int, not T. This produced type-variable-out-of-scope consistency check failures.
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.
