This is in preparation for a subsequent commit where we add special
handling for paths in the template, allowing them to be qualified
differently in different contexts.
Previously we had:
- Multiple rules
- Each rule had its pattern parsed as an expression, path etc
This meant that there were two levels at which there could be multiple
rules.
Now we just have multiple rules. If a pattern can parse as more than one
kind of thing, then they get stored as multiple separate rules.
We also now don't have separate fields for the different kinds of things
that a pattern can parse as. This makes adding new kinds of things
simpler.
Previously, add_search_pattern would construct a rule with a dummy
replacement. Now the replacement is an Option. This is slightly cleaner
and also opens the way for parsing the replacement template as the same
kind of thing as the search pattern.
5507: Require quotes around key-value cfg flags in rust-project.json r=matklad a=matklad
This matches rustc command-line flags, as well as the build.rs format.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
5498: assists: change_return_type_to_result: clarify assist description r=matklad a=matthiaskrgr
I had a -> Option<PathBuf> fn, which I wanted to change to Result<PathBuf, _>, but despite advertising to do so, the assist did not change the result type to Result<PathBuf, _> but instead just wrapped it in a Result: <Result<Option<PathBuf>, _>.
I changed the assist description to "Wrap return type in Result" to clarify that the assist only wraps the preexisting type and does not do any actual Option-to-Result refactoring.
Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
5480: Fix snippetTextEdits applying to other files r=matklad a=TimoFreiberg
Fixes#4551
`vscode.window.visibleTextEditors` only contains editors whose contents are being displayed at the moment, so the previous logic only worked if the other file for which a snippetTextEdit is being received was visible in a separate split.
I feel that this is a hacky approach, so feel free to reject it for something nicer :)
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
5497: Store macro invocation parameters as text instead of tt r=jonas-schievink a=lnicola
We don't want to expand macros on every source change because it can be arbitrarily slow, but the token trees can be rather large. So instead we can cache the invocation parameters (as text).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
I had a -> Option<PathBuf> fn, which I wanted to change to Result<PathBuf, _>, but despite advertising to do so, the assist did not
change the result type to Result<PathBuf, _> but instead just wrapped it in a Result: <Result<Option<PathBuf>, _>.
I changed the assist description to "Wrap return type in Result" to clarify that the assist only wraps the preexisting type and does
not do any deep Option-to-Result refactoring.
vscode.window.visibleTextEditors only contains editors whose contents
are being displayed at the moment, so the previous logic only worked if
the other file for which a snippetTextEdit is being received was visible
in a separate split.
5481: Track document versions in the server r=kjeremy a=kjeremy
This also pushes diagnostics for the correct file version on close so that when it is reopened stale diagnostics are not shown.
Closes#5452
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
5487: Setup global allocator in the correct crate r=matklad a=matklad
It worked before, but was roundabout
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
5478: Replace existing visibility modifier in fix_visibility r=matklad a=TimoFreiberg
Fixes#4636
I would have liked to do something about the `// FIXME: this really should be a fix for diagnostic, rather than an assist.`, but that would take a while and there's no reason not to fix this immediately.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
5479: Allow gathering memory stats on non-jemalloc Linux r=matklad a=jonas-schievink
I could also parse `/proc/$PID/statm` to get the resident set size, but decided against that for now as it isn't terribly useful.
Note that `mallinfo()` is incredibly slow for some reason, and unfortunately this will be exposed to users via the "Memory Usage" command (even worse, the opened document will show the outdated values while the server is processing). So, not very ideal, but it keeps me from recompiling r-a with different feature sets all the time.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
