2585: Cleanup Vim and NeoVim instructions. Fix#2579 r=oblitum a=oblitum
I took some freedom to remove additional tips that I simply considered unnecessary as I view it as responsibility of plugin's own docs.
Co-authored-by: Francisco Lopes <francisco@oblita.com>
Note: we meed to skip the trivia filter to make sure that
`covers!(call_info_bad_offset)` succeeds otherwise we exit call_info
too early.
Also the test doesn't pass: `FnCallNode::with_node` always detects
a MacroCall.
2545: Add Token id to all tt::TokenTree r=matklad a=edwin0cheng
This PR try to add token id to all `tt::Leaf` and `tt::Delimiter`.
~~Some tests are failed now because of #2544~~
~~Still blocked by a test in goto-definition : see https://github.com/rust-analyzer/rust-analyzer/pull/2544#issuecomment-565572553~~
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2575: [VS Code Extension] Remap error location if it extracted inside macros r=edwin0cheng a=edwin0cheng
It should fix for #2569
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2583: Use prettier settings in ts-lint r=matklad a=edwin0cheng
This PR add `tslint-plugin-prettier` extension in ts-lint, which "runs prettier rules as tslint rules." and remove `quotemark` from ts-lint and let prettier to handle it.
And also fix#2515
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2562: Fix NavigationTarget ranges r=matklad a=edwin0cheng
Fix the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/2544#issuecomment-565572553
This PR change the order for finding `full_range` of `focus_range` in following orders:
1. map both ranges to macro_call
2. map focus range to a token inside macro call, and full range to the whole of macro call
3. map both ranges to the whole of macro call
And fix the corresponding tests and make these tests easily to follow.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2568: Add option to disable all-targets. r=matklad a=pftbest
Can be useful in embedded.
Co-authored-by: Vadzim Dambrouski <vadzim.dambrouski@promwad.com>
2571: Fixed a typo in settings r=matklad a=omerbenamram
@lnicola found a typo in the description for one of the settings introduced in #2559.
Co-authored-by: Omer Ben-Amram <omerbenamram@gmail.com>
2567: Handle impl Trait more correctly r=flodiebold a=flodiebold
When calling a function, argument-position impl Trait is transparent; same for return-position impl Trait when inside the function.
So in these cases, we need to represent that type not by `Ty::Opaque`, but by a type variable that can be unified with whatever flows into there.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
When calling a function, argument-position impl Trait is transparent; same for
return-position impl Trait when inside the function. So in these cases, we need
to represent that type not by `Ty::Opaque`, but by a type variable that can be
unified with whatever flows into there.
2565: Fixed syntax highlighting not refreshing on windows. r=matklad a=omerbenamram
I was encoutering the same probelm described in #1690.
It seems that events initiated by the frontend with `rust-analyzer/decorationsRequest` would go through.
So whenever a user switches tabs, highlighting will update.
However, when decorations are initiated by a notification with `rust-analyzer/publishDecorations`, it would fail on this check here 6cbd8a4a4b/editors/code/src/notifications/publish_decorations.ts (L15) (`targetEditor` will always be `undefined`).
This is because it's trying to match the uri `rust-analyzer` sends (which uses an uppercase drive letter) to the uri provided at `editor.document.uri.toString()`, which is both escaped (uses `%3a` for `:`), and uses a lowercase letter drive.
Aparrently this was an issue for some other extensions aswell - https://github.com/Microsoft/vscode/issues/68325.
But this is the defined behavior - c110d84460/src/vs/vscode.d.ts (L1304)
This fix is only relevant for windows.
I've opted for a server-side fix, since rust will always return uppercase letters for drives, there seems to be no other easy solution than manipulating the Url string before sending it to the frontend.
Closes#1690.
Co-authored-by: Omer Ben-Amram <omerbenamram@gmail.com>
