Rust-analyzer turned out to be quite picky about paths, where
`//?/`-prefixed paths can lead to flaky failures. See
https://github.com/rust-lang/rust-analyzer/issues/18894
for details.
This makes paths always be canonicalized with `dunce`. Previously,
`dunce` was used as a fallback, but that stopped working somewhere
after version 0.0.248 of rust-analyzer.
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
```
Users will still be able to opt out:
* for unit tests, by providing the `cargo_cfg_overrides=-test` extractor
option
* for integration tests, by excluding the test files from the analysis
using `paths-ignore` in the codescanning configuration file
We may want to revisit whether we want a single option for both. Also
further work will be needed to restrict our security queries to non-test
code on the QL side.
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.
