2cd58817d7
This is a developer QoL improvement, where running codegen will skip writing (and especially formatting) any files that were not changed. **Why?** While code generation in itself was pretty much instant, QL formatting of generated code was starting to take a long time. This made unconditionally running codegen quite annoying, for example before each test run as part of an IDE workflow or as part of the pre-commit hook. **How?** This was not completely straightforward as we could not work with the contents of the file prior to code generation as that was already post-processed by the QL formatting, so we had no chance of comparing the output of template rendering with that. We therefore store the hashes of the files _prior_ to QL formatting in a checked-in file (`swift/ql/.generated.list`). We can therefore load those hashes at the beginning of code generation, use them to compare the template rendering output and update them in this special registry file. **What else?** We also extend this mechanism to detect accidental modification of generated files in a more robust way. Before this patch, we were doing it with a rough regexp based heuristic. Now, we just store the hashes of the files _after_ QL formatting in the same checked file, so we can check that and stop generation if a generated file was modified, or a stub was modified without removing the `// generated` header.
Swift on CodeQL
Warning
The Swift CodeQL package is an experimental and unsupported work in progress.
Building the Swift extractor
First ensure you have Bazel installed, for example with
brew install bazelisk
then from the ql directory run
bazel run //swift:create-extractor-pack # --cpu=darwin_x86_64 # Uncomment on Arm-based Macs
which will install swift/extractor-pack.
Notice you can run bazel run :create-extractor-pack if you already are in the swift directory.
Using codeql ... --search-path=swift/extractor-pack will then pick up the Swift extractor. You can also use
--search-path=., as the extractor pack is mentioned in the root codeql-workspace.yml. Alternatively, you can
set up the search path
in the per-user CodeQL configuration file
.
Code generation
Run
bazel run //swift/codegen
to update generated files. This can be shortened to
bazel run codegen if you are in the swift directory.
IDE setup
CLion and the native bazel plugin
You can use CLion with the official IntelliJ Bazel plugin, creating the project from scratch with default options. This is known to have issues on non-Linux platforms.
CMake project
The CMakeLists.txt file allows to load the Swift extractor as a CMake project, which allows integration into a wider
variety of IDEs. Building with CMake also creates a compile_commands.json compilation database that can be picked up
by even more IDEs. In particular, opening the swift directory in VSCode should work.
Debugging codeql database creation
If you want to debug a specific run of the extractor within an integration test or a complex codeql database create
invocation, you can do so using gdbserver or lldb-server.
For example with gdbserver, you can
export CODEQL_EXTRACTOR_SWIFT_RUN_UNDER="gdbserver :1234"
export CODEQL_EXTRACTOR_SWIFT_RUN_UNDER_FILTER="SomeSwiftSource\.swift" # can be any regex matching extractor args
before starting the database extraction, and when that source is encountered the extractor will be run under
a gdbserver instance listening on port 1234. You can then attach to the running debugging server from gdb or your
IDE. Please refer to your IDE's instructions for how to set up remote debugging.
In particular for breakpoints to work you might need to setup the following remote path mapping:
| Remote | Local |
|---|---|
swift |
/absolute/path/to/codeql/swift |
bazel-out |
/absolute/path/to/codeql/bazel-out |