* do not mention any more that one might make analysis happen on Linux with
advanced setup
* say that outright Swift analysis is only supported on macOS, not just
autobuild.
* emit the error diagnostics even for traced builds, not only for autobuilds
(by using a dummy `extractor` executable).
Previously, we were using 8.0.0rc1.
In particular, this upgrade means we need to explicitly
import more rules, as they've been moved out of the core bazel repo.
This encapsulate arch specific logic, local installation and separation
of zip files into generic and arch-specific parts as required by the
internal build.
The test sdk that we were prebuilding to run ql tests is actually not
needed, as the `resource-dir` we package for cross-version compatibility
is enough for running qltests as well.
This fetches the resource directory directly from the released
toolchains, allowing us to stop prebuilding and assembling them.
Moreover insertion of our resource directory is moved to the lua
tracing configuration (solving a `TODO`) and enhanced. Now all options
that start with the original resource directory (either explicit or
implied) are redirected to our resource directory.
This solves a problem where `-I <original resource dir>/some/path` was
passed to the extractor and did not work.
This works around the 5.9 linux compatibility problem by including the
`PackageDescription` swift modules in the in-dist toolchain. Copying the
toolchain and fixing the `-I` flag was not enough as for some reason
compilation of `PackageDescription.swiftinterface` was causing a crash
in the SIL pass. We work around that by pre-compiling those modules
during the build and including `.swiftmodule` files in the resource
directory.
TODO (apart from testing):
* the libraries included in the macOS toolchain are now fat (they were
intel only before), occupying more space. We should see if we need to
trim them down.
* there might be other swiftinterface files causing problems on linux
lurking around...
* if we go with this, we can simplify and trim down the prebuilding we
do leaving out the resource directory.
The bazel -> cmake generator is currently not capable of handling
separate included generated cmake files making use of common C/C++
dependencies.
To work around this limitation, a single generated cmake is now in
place. Long-term, we should either:
* make the cmake generator handle common dependencies gracefully, or
* make the cmake generation aspect travel up `pkg_` rules `srcs`
attributes
so to avoid having to list the targets to be generated in the top-level
`BUILD` file.
Other things fixed:
* removed some warning spam about redefined `BAZEL_CURRENT_REPOSITORY`
* fixed the final link step, that was failing because `libswiftCore.so`
was not being linked.
While I would have preferred to add a proper unit test, this required
more infrastructure for mocking system calls. Instead I made `qltest.sh`
accept a `//codeql-extractor-env` header and used that to write a QL
test exercising the `RUN_UNDER` functionality.
