aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Use chalk_ir::ClosureIdFlorian Diebold2021-03-135-23/+17
|
* Merge #7999bors[bot]2021-03-132-29/+22
|\ | | | | | | | | | | | | | | | | | | 7999: Handle `cfg_attr` gating multiple attributes r=jonas-schievink a=jonas-schievink Apparently `#[cfg_attr(cfg_expr, attr1, attr2)]` is valid, so let's add support for that. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Handle `cfg_attr` gating multiple attributesJonas Schievink2021-03-131-29/+19
| |
| * Extend cfg_attr testJonas Schievink2021-03-131-0/+3
|/
* Merge #7998bors[bot]2021-03-1314-135/+158
|\ | | | | | | | | | | | | | | 7998: Use more Chalk IDs r=flodiebold a=flodiebold Co-authored-by: Florian Diebold <[email protected]>
| * Use chalk_ir::FnDefIdFlorian Diebold2021-03-1310-30/+48
| |
| * Use chalk_ir::AssocTypeIdFlorian Diebold2021-03-1310-76/+87
| |
| * Use chalk_ir::ForeignDefIdFlorian Diebold2021-03-136-38/+32
|/
* Merge #7997bors[bot]2021-03-131-1/+2
|\ | | | | | | | | | | | | | | | | 7997: fix folding range kind r=matklad a=matklad bors r+ đŸ¤– Co-authored-by: Aleksey Kladov <[email protected]>
| * fix folding range kindAleksey Kladov2021-03-131-1/+2
|/
* Merge #7996bors[bot]2021-03-1320-619/+755
|\ | | | | | | | | | | | | | | | | 7996: Separate `Ty` and `TyKind` like in Chalk r=flodiebold a=flodiebold Currently `Ty` just wraps `TyKind`, but this allows us to change most places to already use `intern` / `interned`. Co-authored-by: Florian Diebold <[email protected]>
| * Separate `Ty` and `TyKind` like in ChalkFlorian Diebold2021-03-1320-619/+755
|/ | | | | Currently `Ty` just wraps `TyKind`, but this allows us to change most places to already use `intern` / `interned`.
* Merge #7799bors[bot]2021-03-1313-28/+471
|\ | | | | | | | | | | | | | | | | | | | | | | | | 7799: Related tests r=matklad a=vsrs ![tests](https://user-images.githubusercontent.com/62505555/109397453-a9013680-7947-11eb-8b11-ac03079f7645.gif) This adds an ability to look for tests for the item under the cursor: function, constant, data type, etc The LSP part is bound to change. But the feature itself already works and I'm looking for a feedback :) Co-authored-by: vsrs <[email protected]>
| * Fix LSP extensions documentationvsrs2021-03-111-7/+2
| |
| * Add `Feature: Related Tests` commentvsrs2021-03-111-0/+13
| |
| * Apply review suggestionsvsrs2021-03-115-18/+11
| |
| * Remove erroneous commentvsrs2021-02-272-11/+1
| |
| * Update lsp-extensions.mdvsrs2021-02-271-1/+22
| |
| * Add progress reportingvsrs2021-02-272-17/+25
| |
| * Add LSP request and VSCode commandvsrs2021-02-277-9/+96
| |
| * Remove unnecessary file_id argumentvsrs2021-02-272-10/+7
| |
| * Add runnables::related_testsvsrs2021-02-274-7/+346
| |
* | Merge #7981bors[bot]2021-03-131-11/+76
|\ \ | | | | | | | | | | | | | | | | | | | | | 7981: Allow applying De Morgan's law to multiple terms at once r=matklad a=shepmaster Co-authored-by: Jake Goulding <[email protected]>
| * | Allow applying De Morgan's law to multiple terms at onceJake Goulding2021-03-121-11/+76
| | |
* | | Merge #7984bors[bot]2021-03-132-6/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7984: Improve version display r=matklad a=lnicola Maybe closes #7854 The version string for unreleased builds looks like this now: ``` $ rust-analyzer --version rust-analyzer 2021-03-08-159-gc0459c535 ``` Release builds should only have the tag name (`2021-03-15`). Co-authored-by: LaurenÈ›iu Nicola <[email protected]>
| * | | Improve version displayLaurențiu Nicola2021-03-122-6/+4
| |/ /
* | | Merge #7994bors[bot]2021-03-135-67/+270
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7994: Speed up mbe matching in heavy recursive cases r=edwin0cheng a=edwin0cheng In some cases (e.g. #4186), mbe matching is very slow due to a lot of copy and allocation for bindings, this PR try to solve this problem by introduce a semi "link-list" approach for bindings building. I used this [test case](https://github.com/weiznich/minimal_example_for_rust_81262) (for `features(32-column-tables)`) to run following command to benchmark: ``` time rust-analyzer analysis-stats --load-output-dirs ./ ``` Before this PR : 2 mins After this PR: 3 seconds. However, for 64-column-tables cases, we still need 4 mins to complete. I will try to investigate in the following weeks. bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * | | Add bindings builder for speed up matchingEdwin Cheng2021-03-133-67/+221
| | | |
| * | | add expand logEdwin Cheng2021-03-132-0/+49
| | | |
* | | | Merge #7991bors[bot]2021-03-131-7/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7991: Simplify hir_def TestDB r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | | Simplify hir_def TestDBJonas Schievink2021-03-131-7/+2
|/ / / /
* | | | Merge #7989bors[bot]2021-03-122-18/+4
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7989: Remove `ItemTree::source` r=jonas-schievink a=jonas-schievink `HasSource` should be used instead bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | | Remove `ItemTree::source`Jonas Schievink2021-03-122-18/+4
|/ / / / | | | | | | | | | | | | `HasSource` should be used instead
* | | | Merge #7986bors[bot]2021-03-121-10/+5
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7986: Simplify a bit r=flodiebold a=flodiebold Co-authored-by: Florian Diebold <[email protected]>
| * | | | Simplify a bitFlorian Diebold2021-03-121-10/+5
|/ / / /
* | | | Merge #7985bors[bot]2021-03-125-55/+44
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | 7985: Use Chalk Environment more directly r=flodiebold a=flodiebold Co-authored-by: Florian Diebold <[email protected]>
| * | | Use Chalk Environment more directlyFlorian Diebold2021-03-125-55/+44
|/ / /
* | | Merge #7956bors[bot]2021-03-124-0/+283
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7956: Add assist to convert for_each into for loops r=Veykril a=SaiintBrisson This PR resolves #7821. Adds an assist to that converts an `Iterator::for_each` into a for loop: ```rust fn main() { let vec = vec![(1, 2), (2, 3), (3, 4)]; x.iter().for_each(|(x, y)| { println!("x: {}, y: {}", x, y); }) } ``` becomes ```rust fn main() { let vec = vec![(1, 2), (2, 3), (3, 4)]; for (x, y) in x.iter() { println!("x: {}, y: {}", x, y); }); } ``` Co-authored-by: Luiz Carlos MourĂ£o Paes de Carvalho <[email protected]> Co-authored-by: Luiz Carlos <[email protected]> Co-authored-by: Lukas Wirth <[email protected]>
| * | | Fix convert_iter_for_each_to_for doctestLukas Wirth2021-03-122-15/+56
| | | |
| * | | fix: generated test fixtureLuiz Carlos MourĂ£o Paes de Carvalho2021-03-122-2/+25
| | | |
| * | | fix: replace doc-comments with normal commentsLuiz Carlos2021-03-121-20/+20
| | | | | | | | | | | | Co-authored-by: Lukas Wirth <[email protected]>
| * | | refactor: refactored and reduced assist codeLuiz Carlos MourĂ£o Paes de Carvalho2021-03-121-36/+21
| | | |
| * | | fix: remove semicolonLuiz Carlos MourĂ£o Paes de Carvalho2021-03-101-29/+56
| | | |
| * | | fix: code formattingLuiz Carlos MourĂ£o Paes de Carvalho2021-03-101-10/+20
| | | |
| * | | 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
| | | | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 00:27:32 +0000