This collapses all generated test QL sources into a single one per
directory, using query predicates to run the different tests.
This should improve the time required to run generated tests.
This improves the implementation of the generated parent/child
relationship by adding a new `all_children` field to `ql.Class` which
lists all children (both direct and inherited) of a class, carefully
avoiding duplicating children in case of diamond inheritance. This:
* simplifies the generated code,
* avoid children ambiguities in case of diamond inheritance.
This only comes with some changes in the order of children in the
generated tests (we were previously sorting bases alphabetically there).
For the rest this should be a non-functional change.
This switched `codegen` from the `autopep8` formatting to the `black`
one, and applies it to `bulk_mad_generator.py` as well. We can enroll
more python scripts to it in the future.
This is a small devex improvement to the rust code generator.
Usage of `sorted` in `rustgen.py` was causing the generated code to be
completely reshuffled on renames, which made diffs hard to follow. As an
example see [this generated file diff](https://github.com/github/codeql/pull/19059/files#diff-c938ba77a3398dd4c633ada5702a03477705c24740a2f7d1e40d4b270d8c3f86).
This will make the order deterministically based on the order of
definitions in the schema file. This means that renames will find the
same place in the generated file, and the place in the generated file
will generally be more predictable with respect to the schema.
However, that does mean this change is heavily reshuffling the generated
code.
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 adds a `ql.name` codegen pragma to change the name of a property on
the QL side. This is useful to give more meaningful names than what we
get from the generated rust AST.
By using the `rust.detach` pragma on a property, we make that property
not appear in the generated struct as a field, and provide instead
a `generated::Class::emit_property` function that can be used to emit
the corresponding TRAP entry independently.
This generates test source files from code blocks in class docstrings.
By default the test code is generated as is, but it can optionally:
* be wrapped in a function providing an adequate context using
`@rust.doc_test_function(name, *, lifetimes=(), return_type="()", **kwargs)`,
with `kwargs` providing both generic and normal params depending on
capitalization
* be skipped altogether using `@rust.skip_doc_test`
So for example an annotation like
```python
@rust.doc_test_function("foo",
lifetimes=("a",),
T="Eq",
x="&'a T",
y="&'a T",
return_type="&'a T")
```
will result in the following wrapper:
```rust
fn foo<'a, T: Eq>(x: &'a T, y: &'a T) -> &'a T {
// example code here
}
```
This introduces tooling and enforcement for formatting bazel files.
The tooling is provided as a bazel run target from
[keith/buildifier-prebuilt](https://github.com/keith/buildifier-prebuilt).
This is used in a [`pre-commit`](https://pre-commit.com/) hook for those
having that installed. In turn this is used in a CI check. Relying on a
`pre-commit` action gives us easy checking that buildifying did not
change anything in the files and printing the diff, without having to
hand-roll the check ourselves.
This enforcement will make usage of gazelle easier, as gazelle itself
might reformat files, even outside of `go`. Having them properly
formatted will allow gazelle to leave them unchanged, without needing
to configure awkward exclude directives.
