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.
This allows to group together related AST classes to reuse the same
test source and extraction. For example this is useful for
`EnumDecl/EnumCaseDecl/EnumElementDecl`, where this is applied to.
This simplifies several instances of metaprogramming by leveraging
[constraints and concepts from C++20][1]. This:
* gets rid of `std::enable_if` by usage of `requires`, making it more
readable and yield better compiler messages.
* uses `requires` instead of `static_assert` to enforce `TrapLabel`
typing
* simplifies all compile-time tests for validity of a given expression
* uses some standard library concepts where possible
* generalizes and simplifies `SwiftLocationExtractor`
Notice that in order to use the `std::derived_from` concept, `virtual`
inheritance had to be added to the label tags, because diamond
inheritance is a problem otherwise. That's because
`std::derived_from<T, U>` requires that `T*` be convertible to `U*`,
which is false if there are multiple non-virtual inheritance paths from
`U` to `T`. As tags never get actually instantiated, there is no runtime
performance penalty in using `virtual` inheritance.
[1]: https://en.cppreference.com/w/cpp/language/constraints
