This splits the `ArrayExpr` class into `ArrayListExpr` and `ArrayRepeatExpr`.
This uses the `synth.from_class` machinery to integrate seamlessly into the
generated code, by hiding the extracted `ArrayExpr` behind an internal class
and replacing it with a hierarchy of those two classes under a new
`ArrayExpr` class.
This outputs some duration counts for various parts of the extraction
process in the database in the form of telemetry diagnostics.
The diagnostics format was preferred to putting things in the relational
database as that will scale better to code scanning and is more flexible
as for the data we can put into it without passing through the dbscheme.
Also, although it's not the case yet, it will be possible to output
diagnostics even if creation of the database fails.
This doesn't require `ql.name` and is simpler while we don't have
to write upgrade scripts. The `ql.name` mechanism might get useful
once we do have to write upgrade scripts, as that doesn't change the
dbscheme.
Also accept `options.yml` and `options.yaml` files as well for test options,
to get YAML syntax highlighting. In a follow up PR we might make the extension
mandatory.
We've been observing some performance issues using crate_universe on CI.
Therefore, we're moving to vendor the auto-generated BUILD files
in our repository. This should provide a nice speed boost, while
getting rid of the complexity of the "rust cache" job we've been using
when we had a lot of git dependencies.
This PR includes a vendor script, and I'll put up a CI job internally
that runs that vendor script on Cargo.toml and Cargo.lock changes, to check
that the vendored files are in sync.
This allows to tweak via extractor options some aspects of the cargo
configuration:
* the target architecture
* features (including `*` for all, which we must understand whether to
set by default)
* cfg overrides
Integration tests will be added in a follow-up commit.