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.
We were escaping '/', but I don't think there is any need to do so. It
just happens to have a nice escape in the spec. Escaping it might
filenames annoying to work with.
I've also added escaping for the other control characters that we're
meant to escape.
We were getting
DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
during the build.
This will allow the extractor to emit class(id, ...) when all it knows about a class is its name, due to not having it available on the classpath. Previously it would have had to guess whether it belonged to @class or @interface, possibly introducing an inconsistency.
The build no longer works for Kotlin < 1.8: We get
error: class 'org.jetbrains.kotlin.ir.IrElement' was compiled
with an incompatible version of Kotlin. The binary version
of its metadata is 1.8.0, expected version is 1.6.0.
This imprecise implementation turned out to cause linkage errors, e.g. when type variables in the signatures of member methods were inappropriately erased. For the time being we accept that $default methods despite having erased signatures in keeping with their JVM representation can contain expressions whose types make reference to their
surrounding function or class' type variables, even though they should be out of scope since $default methods are static and don't have type parameters, and need to cope with the inconsistency in QL.
This is imperfect since arguments to those annotations will be missing, but at least the common case of a plain `@NotNull` or `@Nullable` will be right, and the `@NotNull`s introduced by the Kotlin compiler will be present as expected.
This is a shortcoming of the Kotlin extractor, but at least this way we don't introduce an inconsistency if the annotation is later seen from .kt source or by the Java extractor
