3580: More error-resilient MBE expansion r=matklad a=flodiebold
This is the beginning of an attempt to make macro-by-example expansion more resilient, so that we still get an expansion even if no rule exactly matches, with the goal to make completion work better in macro calls.
The general idea is to make everything return `(T, Option<ExpandError>)` instead of `Result<T, ExpandError>`; and then to try each macro arm in turn, and somehow choose the 'best' matching rule if none matches without errors. Finding that 'best' match isn't done yet; I'm currently counting how many tokens were consumed from the args before an error, but it also needs to take into account whether there were further patterns that had nothing to match.
I'll continue this later, but I'm interested whether you think this is the right path, @matklad & @edwin0cheng.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3614: Separate persistent mutable state from config r=matklad a=matklad
That way, we clearly see which things are not change, and we also
clearly see which things are persistent.
r? @Veetaha
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3584: Switch to dynamic dispatch r=matklad a=matklad
Benches are in https://github.com/rust-analyzer/rust-analyzer/issues/1987#issuecomment-598807185
TL;DR:
* 33% faster release build
* slightly worse/same perf
* no changes for debug build
* slightly smaller binary
cc @flodiebold I genuinely don't know if it is a good idea or not.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
3573: Check all crates of the workspace r=matklad a=matklad
Previously, if the root of the was was a real crate, only this crate
was checked.
Ideally, we might want some kind of config here (which might be just
overriding the whole command), but `--workspace` is def a nicer
default.
r? @kiljacken
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3587: Use WorkDoneProgress LSP API for initial load r=matklad a=slyngbaek
Addresses #3283
Rather than using custom UI for showing the loaded state. Rely
on the WorkDoneProgress API in 3.15.0
https://microsoft.github.io/language-server-protocol/specification#workDoneProgress.
No client-side work was necessary. The UI is not exactly what is
described in the issue but afaict that's how VS Code implements the LSP
API.
- The WorkDoneProgressEnd does not appear to display its message
contents (controlled by vscode)
Co-authored-by: Steffen Lyngbaek <steffenlyngbaek@gmail.com>
