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.
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.
If:
* the text for a file_id is not found (likely non-utf data in file)
* path does not appear in Vfs, in which case we fall back on loading the file from disk with no "semantics" available
Files were reloaded to handle cases were there was no content
for a file_id, causing a panic. Missing contents was caused by
files that did not contain valid UTF-8 data. These are skipped
by rust-analyzer when it is loading data into the RootDatabase.
