Split out project loading capabilities from rust-analyzer crate
External tools currently depend on the entire lsp infra for no good reason so let's lift that out so those tools have something better to depend on
Clean up `ImportMap`
There are several things in `hir_def::import_map` that are never used. This PR removes them and restructures the code. Namely:
- Removes `Query::name_only`, because it's *always* true.
- Because of this, we never took advantage of storing items' full path. This PR removes `ImportPath` and changes `ImportInfo` to only store items' name, which should reduce the memory consumption to some extent.
- Removes `SearchMode::Contains` for `Query` because it's never used.
- Merges `Query::assoc_items_only` and `Query::exclude_import_kinds` into `Query::assoc_mode`, because the latter is never used besides filtering associated items out.
Best reviewed one commit at a time. I made sure each commit passes full test suite. I can squash the first three commits if needed.
internal: Add analysis-stats flag to trigger some IDE features
Closes https://github.com/rust-lang/rust-analyzer/issues/15131
Running this on r-a showed an 86mb memory increase, but that was without running it on the deps, will try that later when I don't need to use my pc.
Shuffle some proc_macro_expand query things around
Removes some unnecessary extra work we are doing in proc-macro expansion, and more importantly `Arc` the result of the proc_macro_expand query, that way we can reuse the instance for the `macro_expand` query's result
feat: don't add panics to error jump list by default
To re-enable this, use
"rust-analyzer.runnables.problemMatcher": [
"$rustc",
"$rust-panic"
],
setting.
closes: #14977
Don't specify proc-macro-test version
proc-macro-test is only used as a dev-dependency and isn't published to crates.io, so a version doesn't make sense. Having a version also breaks automatic publishing.
proc-macro-test is only used as a dev-dependency and isn't published to
crates.io, so a version doesn't make sense. Having a version also breaks
automatic publishing.
Use anonymous lifetime where possible
Because anonymous lifetimes are *super* cool.
More seriously, I believe anonymous lifetimes, especially those in impl headers, reduce cognitive load to a certain extent because they usually signify that they are not relevant in the signature of the methods within (or that we can apply the usual lifetime elision rules even if they are relevant).