While you could control compression with
CODEQL_EXTRACTOR_JAVA_OPTION_TRAP_COMPRESSION
before, most TRAP files used gzip regardless for compatibility with the
Java extractor. Now Java understands the option too we can use it for
shared TRAP files.
In some cases, we were writing diagnostics to TRAP files where they
shouldn't be written. Such TRAP files don't define #compilation, so TRAP
import gave errors.
Now we use DiagnosticTrapWriter to get the type system to check that we
are writing diagnostics to the right place.
This generates functions that omit parameters with default values, rightmost first, such that Java can achieve a similar experience to Kotlin (which represents calls internally as if the default was supplied explicitly, and/or uses a $default method that supplies the needed arguments).
A complication: combining JvmOverloads with JvmStatic means that both the companion object and the surrounding class get overloads.
The Kotlin extractor can now be told to write TRAP with no compression,
gzip compression or Brotli compression - although Brotli is not yet
supported and it will fall back to gzip.
The invocation TRAP file is a bit more complicated, as it's already been
started before the extractor starts. For now that continues to always be
uncompressed.
We had a global set of labels for generic specialisations that we'd
extracted, but these labels could contain references to other labels,
and thus you can get false collisions between labels for different TRAP
files. We now only keep the set for a single TRAP file, and live with
the extra TRAP duplication that we get from that.
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
We now get e.g.
[2022-03-09 13:59:04 K] [ERROR] Diagnostic(com.github.codeql.KotlinUsesExtractor.useSimpleType(KotlinUsesExtractor.kt:505)): Type alias ignored for <root>.Test<kotlin.String>{ <root>.Alias1<kotlin.String> }
...while extracting a function at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a function if real at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a declaration at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a file at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:1:1:8:0
In particular, we now write full exception information, so we can
diagnose problems.
We were using `warn` to log errors in some cases, and generally using
lower-level functions than necessary. We now use the appropriate
functions. I've lost the distinction between e.g. ErrorHigh and ErrorSevere
in this, but we can add it back if it's important.
