Also:
* remove new warnings raised by the rust toolchain
* run new formatting and linting
* update the rust toolchain used by `cargo`
While we keep `bazel` builds using the same toolchain as internally
(now a nightly one), I opted for using a stable toolchain for `cargo`.
The nightly toolchain is only required internally for build reasons, we
should keep not using any unstable rust features in our sources.
There was a mismatch between a `self.macro_context_level += 1` and the
corresponding `self.macro_context_level -= 1`, which resulted in an
`usize` underflow (panic in debug mode, wrong behaviour in release
mode).
This fixes it and adds a relevant assertion and test. In order to
properly test library mode extraction, a special option enforcing that
on source code as well is added.
Since we dropped checked in toolchain files for tests requiring nightly,
the `setup.sh` script was not doing its job of setting up the toolchains
and the `rust-src` component, occasionally leading to test failures.
Rather than fixing the version separately for each test, we can just
request to use a nightly in the `options.yml` file, with the specific
version hard-coded in `qltest.rs`. We can update it if we need to.
It's better to have a single nightly version for all tests that require
it, in order to avoid downloading more versions than necessary.
Supports only a minimal subset of the project layout specification;
enough to work with the transformers produced by the CLI when building
an overlay database.
This adds the possibility to add a special `proc_macro.rs` source file
to QL tests, which will be generated into a `proc_macro` crate the
usual `lib` crate depends on.
This allow to define procedural macros in QL tests, and is here used to
move the `macro-expansion` integration test to be a language test
instead.
As the generated manifests involved were starting to get a bit complex,
they are now generated from a `mustache` template.
When skipping bodies in library code, we lose the information whether a
body was originally present. This can be important, for example when
determining whether a trait method has a default implementation.
With this change that information can be recovered via the
`hasImplementation` predicate.
