While the (removed) comment is correct and the frontend can be called in
different modes, both `swift build` and `xcodebuild` always use
`-primary-files` when compiling Swift projects.
The other mode was present only within our test runner (`qltest.sh`), so
removing it and doing what the official build systems do simplifies our
code base.
Additionally, file archival is now a separate function/operation.
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.
Python code was simplified, and now a `--generate` option can be used
to drive what can be generated.
The extractor pack creation now will use an internally generated
dbscheme. This should be the same as the checked in one, but doing so
allows `bazel run create-extractor-pack` and `bazel run codegen` to be
run independently from one another, while previously the former had to
follow the latter in case of a schema change. This is the change that
triggered the above simplification, as in order for the two dbscheme
files to be identical, the first `// generated` line had to state the
same generator script.
By explicitly marking children in the `schema.yml` file, an internal
`getAChild` predicate is implemented, that is in turn used in `AstNode`
to implement `getParent`.
This is yet to be used in the control flow library to replace the
hand-rolled implementation.
A further, more complex step is to use the same information to fully
generate the core implementation of `PrintAst` (including the
accessor string). This will be done later.
The `parent` tests use the same swift code as the extractor tests, and
this is currently enforced by `sync-files.py`. Notice that `qltest.sh`
had to be modified to deal with multiple files, which was not working
yet.
