aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | fix: tests should work for convert_iter_for_each_to_forLuiz Carlos Mourão Paes de Carvalho2021-03-101-11/+44
| | | | | |
| * | | | | refactor: create block expressions and for loops using makeLuiz Carlos Mourão Paes de Carvalho2021-03-101-29/+50
| | | | | |
| * | | | | feat: add expr_for_loop to make in syntaxLuiz Carlos Mourão Paes de Carvalho2021-03-101-0/+3
| | | | | |
| * | | | | feat: add assist to conver for_each into for loopsLuiz Carlos Mourão Paes de Carvalho2021-03-102-0/+140
| | | | | |
* | | | | | Merge #7904bors[bot]2021-03-125-46/+140
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7904: Improved completion sorting r=JoshMcguigan a=JoshMcguigan I was working on extending #3954 to apply completion scores in more places (I'll have another PR open for that soon) when I discovered that actually completion sorting was not working for me at all in `coc.nvim`. This led me down a bit of a rabbit hole of how coc and vs code each sort completion items. Before this PR, rust-analyzer was setting the `sortText` field on completion items to `None` if we hadn't applied any completion score for that item, or to the label of the item with a leading whitespace character if we had applied any completion score. Completion score is defined in rust-analyzer as an enum with two variants, `TypeMatch` and `TypeAndNameMatch`. In vs code the above strategy works, because if `sortText` isn't set [they default it to the label](https://github.com/microsoft/vscode/commit/b4ead4ed665e1ce2e58d8329c682f78da2d4e89d). However, coc [does not do this](https://github.com/neoclide/coc.nvim/blob/e211e361475a38b146a903b9b02343551c6cd372/src/completion/complete.ts#L245). I was going to file a bug report against coc, but I read the [LSP spec for the `sortText` field](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion) and I feel like it is ambiguous and coc could claim what they do is a valid interpretation of the spec. Further, the existing rust-analyzer behavior of prepending a leading whitespace character for completion items with any completion score does not handle sorting `TypeAndNameMatch` completions above `TypeMatch` completions. They were both being treated the same. The first change this PR makes is to set the `sortText` field to either "1" for `TypeAndNameMatch` completions, "2" for `TypeMatch` completions, or "3" for completions which are neither of those. This change works around the potential ambiguity in the LSP spec and fixes completion sorting for users of coc. It also allows `TypeAndNameMatch` items to be sorted above just `TypeMatch` items (of course both of these will be sorted above completion items without a score). The second change this PR makes is to use the actual completion scores for ref matches. The existing code ignored the actual score and always assumed these would be a high priority completion item. #### Before Here coc just sorts based on how close the items are in the file. ![image](https://user-images.githubusercontent.com/22216761/110249880-46063580-7f2d-11eb-9233-91a2bbd48238.png) #### After Here we correctly get `zzz` first, since that is both a type and name match. Then we get `ccc` which is just a type match. ![image](https://user-images.githubusercontent.com/22216761/110249883-4e5e7080-7f2d-11eb-9269-a3bc133fdee7.png) Co-authored-by: Josh Mcguigan <[email protected]>
| * | | | | | update relevance score u8 -> u32Josh Mcguigan2021-03-122-10/+10
| | | | | | |
| * | | | | | add relevance score testJosh Mcguigan2021-03-121-0/+60
| | | | | | |
| * | | | | | remove unused CompletionScore enumJosh Mcguigan2021-03-123-14/+3
| | | | | | |
| * | | | | | add completion relevance scoreJosh Mcguigan2021-03-125-37/+82
| | | | | | |
* | | | | | | Fix remaining references to `cargo xtask codegen`Lukas Wirth2021-03-121-1/+1
|/ / / / / /
* | | | | | Unify namingAleksey Kladov2021-03-1213-103/+90
| | | | | |
* | | | | | use references in CompletionItem's builderyonip232021-03-1117-166/+183
| | | | | |
* | | | | | fix: add semicolon after type ascriptionConrad Ludgate2021-03-111-3/+30
| |_|_|_|/ |/| | | |
* | | | | Return original text range in PrepareRename responses when inside macroLukas Wirth2021-03-101-7/+47
| | | | |
* | | | | Use expect-test for builtin macro/derive testsJonas Schievink2021-03-103-80/+65
| |_|_|/ |/| | |
* | | | Merge #7965bors[bot]2021-03-101-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7965: cargo update and lexer r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | | cargo update and lexerkjeremy2021-03-101-1/+1
| | | | |
* | | | | Implement builtin `cfg!` macroJonas Schievink2021-03-104-2/+19
|/ / / /
* | | | Merge #7961bors[bot]2021-03-101-0/+9
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7961: add user docs for ssr assist r=JoshMcguigan a=JoshMcguigan @matklad This is a small follow up on #7874, adding user docs for the SSR assist functionality. Since most other assists aren't handled this way I wasn't sure exactly how we wanted to document this, so feel free to suggest alternatives. Co-authored-by: Josh Mcguigan <[email protected]>
| * | | | add user docs for ssr assistJosh Mcguigan2021-03-101-0/+9
| | | | |
* | | | | Prefer names from outer DefMap over extern preludeJonas Schievink2021-03-102-5/+40
| | | | |
* | | | | Merge #7958bors[bot]2021-03-104-2/+15
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7958: Avoid double text edits when renaming mod declaration r=matklad a=Veykril Closes https://github.com/rust-analyzer/rust-analyzer/issues/7916 See https://github.com/microsoft/vscode-languageserver-node/issues/752 for context Co-authored-by: Lukas Wirth <[email protected]>
| * | | | | Avoid double text edits when renaming mod declarationLukas Wirth2021-03-104-2/+15
| |/ / / /
* / / / / add apply ssr assistJosh Mcguigan2021-03-104-1/+300
|/ / / /
* | | | Fix labels for single import assistsKirill Bulatov2021-03-102-20/+12
| | | |
* | | | Stop fetching ItemTrees for no reasonJonas Schievink2021-03-101-14/+1
| | | |
* | | | Merge #6822bors[bot]2021-03-093-3/+154
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6822: Read version of rustc that compiled proc macro r=edwin0cheng a=jsomedon Signed-off-by: Jay Somedon <[email protected]> This PR is to fix #6174. I basically * added two methods, `read_version` and `read_section`(used by `read_version`) * two new crates `snap` and `object` to be used by those two methods I just noticed that some part of code were auto-reformatted by rust-analyzer on file save. Does it matter? Co-authored-by: Jay Somedon <[email protected]> Co-authored-by: Edwin Cheng <[email protected]>
| * | | | use doc-commentsEdwin Cheng2021-03-091-21/+22
| | | | |
| * | | | Print warning if proc-macro built by old rustcEdwin Cheng2021-03-042-73/+148
| | | | |
| * | | | Revise error message regarding metadata versionJay Somedon2021-03-041-10/+6
| | | | | | | | | | | | | | | | | | | | Co-authored-by: Laurențiu Nicola <[email protected]>
| * | | | Update condition check code styleJay Somedon2021-03-041-1/+1
| | | | | | | | | | | | | | | Co-authored-by: Jonas Schievink <[email protected]>
| * | | | Update commentJay Somedon2021-03-041-1/+1
| | | | | | | | | | | | | | | Co-authored-by: Jonas Schievink <[email protected]>
| * | | | Fix multiple issues from code reviewJay Somedon2021-03-042-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * check metadata version * use memmap * use Result instead of unwrap with Jay Somedon <[email protected]>
| * | | | Configure object crate's featureJay Somedon2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Jay Somedon <[email protected]>
| * | | | Read version of rustc that compiled proc macroJay Somedon2021-03-042-10/+74
| | | | | | | | | | | | | | | | | | | | With Jay Somedon <[email protected]>
* | | | | Compilation speedAleksey Kladov2021-03-0910-10/+12
| | | | |
* | | | | Delete `ContainerId`Jonas Schievink2021-03-0911-100/+61
| | | | |
* | | | | Merge #7878bors[bot]2021-03-0915-229/+111
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7878: Remove `item_scope` field from `Body` r=jonas-schievink a=jonas-schievink Closes https://github.com/rust-analyzer/rust-analyzer/issues/7632 Instead of storing an `ItemScope` filled with inner items, we store the list of `BlockId`s for all block expressions that are part of a `Body`. Code can then query the `block_def_map` for those. bors r+ Co-authored-by: Jonas Schievink <[email protected]> Co-authored-by: Jonas Schievink <[email protected]>
| * | | | | Stop using `ContainerId` in `AssocContainerId`Jonas Schievink2021-03-097-12/+12
| | | | | |
| * | | | | Check ancestor maps when computing traits in scopeJonas Schievink2021-03-092-0/+43
| | | | | |
| * | | | | Remove `item_scope` field from `Body`Jonas Schievink2021-03-093-175/+6
| | | | | |
| * | | | | Use `body.block_scopes` in `hir_ty` testsJonas Schievink2021-03-091-6/+14
| | | | | |
| * | | | | Use `body.block_scopes` to validate inner itemsJonas Schievink2021-03-091-3/+8
| | | | | |
| * | | | | Use `body.block_scopes` in `ChildBySource`Jonas Schievink2021-03-091-1/+5
| | | | | |
| * | | | | Store inner `BlockId`s in `Body`Jonas Schievink2021-03-092-1/+6
| | | | | |
| * | | | | Change `ChildBySource` to allow reusing `DynMap`Jonas Schievink2021-03-092-32/+18
| | | | | |
* | | | | | Merge #7945bors[bot]2021-03-094-72/+96
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7945: Future proof completion scores r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | Future proof completion scoresAleksey Kladov2021-03-094-72/+96
| | | | | |
* | | | | | Merge #7942bors[bot]2021-03-094-33/+48
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7942: Show whether a binding is mutable or not on hover r=Veykril a=Veykril bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * | | | | | Show whether a binding is mutable or not on hoverLukas Wirth2021-03-093-28/+47
| | | | | | |