The rust-analyzer update will need more work as it seems to break rust
analysis on windows.
This was carried out using `cargo upgrade` from `cargo-edit`:
* getting exclusions options for rust-analyzer with
```bash
cargo upgrade -i --dry-run | grep -o 'ra_ap_\S\+' | sort -u | sed 's/^/--exclude=/' > /tmp/exclude
```
* running
```bash
cargo upgrade -i $(cat /tmp/exclude)
misc/bazel/3rdparty/update_cargo_deps.sh
```
* The ungram file is now taken from the rust-analyzer dependencies
pulled in by bazel
* the grammar parsing code is not published, so it must be taken
directly from rust-analyzer code. That part should be less prone to be
updated than the ungram file, so it does not necessarily need to be
in sync with the rust-analyzer version is used elsewhere.
* both need some patches. The former is patched during build, the latter
during loading in `MODULE.bazel`.
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.
There was a recent round of tree-sitter-* package releases,
so the latest code is now a) released and b) available on crates.io.
Therefore, move away from the (super slow on CI) git dependencies to released crates instead.
This also includes a run of `cargo update`, so there's a bunch of more changes to the lockfile.
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.
This makes the clap flags overlay over `Config` entirely derived via an
attribute macro. Also, the `--intputs-file` option is replaced by a more
standard and versatile `@` parameter file mechanism.
The `.cargo/config.toml` override based workaround wasn't really
working, as while `cargo build|check` was reading that, `cargo metadata`
wasn't, ending up in a completely broken IDE experience.
For the moment, we just use a unified workspace `Cargo.toml` for all
extractors using the shared tree-sitter code, which has the downside of
making bazel pull in dependencies for all of them, and not being able to
do sparse checkouts for them. We should investigate and rivist this in
the future.
