3706: missing match arms diagnostic r=flodiebold a=JoshMcguigan
Following up on https://github.com/rust-analyzer/rust-analyzer/pull/3689#issuecomment-602718222, this PR creates a missing match arms diagnostic.
At the moment this is a very early draft, but I wanted to open it just to get some initial feedback.
Initial questions:
* Have I roughly created the correct boilerplate?
* Inside the new `validate_match` function:
* Am I correct in thinking I want to do validation by comparing the match arms against `match_expr`? And when analyzing `match_expr` I should be looking at it as a `hir_def::expr::Expr`?
* I mostly copied the chained if-let statements from the struct validation. Shouldn't there be a non-failable way to get an AstPtr from the hir data structures?
Thanks for all the guidance.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3872: fix cargo check config with custom command r=matklad a=JoshMcguigan
fixes#3871
Previously if `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` returned `Some` we'd never execute `set(value, "/checkOnSave/command", command)`, even if the `overrideCommand` was empty.
I am not sure of the best way to prove this, but I believe the LSP clients send this config with a default value if it is not set by the user, which means `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` would return `Some(vec![])` and thus we'd never set the command to the user specified value (in the case of #3871, "clippy").
I have tested this fix manually by installing this modified version of rust-analyzer and verifying I can see clippy lints in my editor (`coc.nvim`) with `rust-analyzer.checkOnSave.command": "clippy"`.
As best I can tell this would have affected rustfmt extra args too, so this PR also applies the same fix there.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3868: Fix Chalk panic r=flodiebold a=flodiebold
Fixes#3865. Basically I forgot to shift 'back' when we got `dyn Trait`s back from Chalk, so after going through Chalk a few times, the panic happened.
And yes, I did run `analysis-stats` now ;)
cc @edwin0cheng
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
3842: Add lib-proc-macro mod in ra_proc_macro_srv r=matklad a=edwin0cheng
This PR add a module in ra_proc_macro_srv, which is just copy & paste from rustc lib_proc_macro and remove all unstable features in it.
The main idea here is by doing that, we could build the `ra_proc_macro_srv` without nightly compiler and remain ABI compatibility.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3864: Use log::info in trait_solve_query instead of eprintln r=edwin0cheng a=edwin0cheng
cc @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
The sytax tree output files now use .rast extension
(rust-analyzer syntax tree or rust abstract syntax tree
(whatever)).
This format has a editors/code/ra_syntax_tree.tmGrammar.json declaration
that supplies nice syntax highlighting for .rast files.
3843: Remove rustc_lexer dependency in favour of rustc-ap-rustc_lexer r=est31 a=est31
The latter is auto-published on a regular schedule (Right now weekly).
See also https://github.com/alexcrichton/rustc-auto-publish
Co-authored-by: est31 <MTest31@outlook.com>
3829: Adds to SSR match for semantically equivalent call and method call r=matklad a=mikhail-m1
#3186
maybe I've missed some corner cases, but it works in general
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
In textmate, keyword.control is used for all kinds of things; in fact,
the default scope mapping for keyword is keyword.control!
So let's add a less ambiguous controlFlow modifier
See Microsoft/vscode#94367
