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>
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
3858: Hide unit function return types r=flodiebold a=lnicola
r? @flodiebold
This might be a bit heavy-handed (e.g. `|| -> ()` to `||`), what do you think?
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
The big change here is counting binders, not
variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the
same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things
more clear.
3844: vscode: restore removed default values r=matklad a=Veetaha
After refactoring the config we forgot to set defaults for
some properties like workspaceLoaded, callInfo.full, etc.
This commit restored them to being turned on by defult,
as well added defaults for other props to be more explicit
on their defualt value.
cc @matklad
Co-authored-by: veetaha <veetaha2@gmail.com>
After refactoring the config we forgot to set defaults for
some properties like workspaceLoaded, callInfo.full, etc.
This commit restored them to being turned on by defult,
as well added defaults for other props to be more explicit
on their defualt value.
3836: Macro patterns are not confused with expressions. r=matklad a=matklad
We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).
We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).
We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
