aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | |
| * | | 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
| | | |
* | | | Merge #7980bors[bot]2021-03-125-7/+7
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | 7980: Fix remaining references to `cargo xtask codegen` r=matklad a=Veykril Co-authored-by: Lukas Wirth <[email protected]>
| * | | Fix remaining references to `cargo xtask codegen`Lukas Wirth2021-03-125-7/+7
|/ / /
* | | Merge #7978bors[bot]2021-03-1213-103/+90
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7978: Unify naming r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Unify namingAleksey Kladov2021-03-1213-103/+90
|/ / /
* | | Merge #7974bors[bot]2021-03-1217-166/+183
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7974: use references in CompletionItem's builder r=matklad a=yonip23 @matklad This is a follow up to [this pr](https://github.com/rust-analyzer/rust-analyzer/pull/7973) Co-authored-by: yonip23 <[email protected]>
| * | | use references in CompletionItem's builderyonip232021-03-1117-166/+183
|/ / /
* | | Merge #7972bors[bot]2021-03-111-3/+30
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7972: fix: add semicolon after type ascription r=matklad a=conradludgate Fixes #7971 Co-authored-by: Conrad Ludgate <[email protected]>
| * | | fix: add semicolon after type ascriptionConrad Ludgate2021-03-111-3/+30
|/ / /
* | | Merge #7969bors[bot]2021-03-101-7/+47
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7969: Return original text range in PrepareRename responses when inside macro r=Veykril a=Veykril bors r+ Issue found in #7968 Co-authored-by: Lukas Wirth <[email protected]>
| * | | Return original text range in PrepareRename responses when inside macroLukas Wirth2021-03-101-7/+47
|/ / /
* | | Merge #7967bors[bot]2021-03-104-80/+66
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7967: Use expect-test for builtin macro/derive tests r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | Use expect-test for builtin macro/derive testsJonas Schievink2021-03-104-80/+66
|/ / /
* | | Merge #7965bors[bot]2021-03-102-9/+9
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7965: cargo update and lexer r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | cargo update and lexerkjeremy2021-03-102-9/+9
| | | |
* | | | Merge #7964bors[bot]2021-03-105-2/+20
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | 7964: Implement builtin `cfg!` macro r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | Implement builtin `cfg!` macroJonas Schievink2021-03-105-2/+20
|/ / /
* | | 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
| | | |
* | | | Merge #7959bors[bot]2021-03-102-5/+40
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7959: Prefer names from outer DefMap over extern prelude r=jonas-schievink a=jonas-schievink Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7919 Just one more special case, how bad could it be. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | | 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
| |/ / /
* | | | Merge #7874bors[bot]2021-03-104-1/+300
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7874: add apply ssr assist r=JoshMcguigan a=JoshMcguigan This PR adds an `Apply SSR` assist which was briefly mentioned in #3186. It allows writing an ssr rule as a comment, and then applying that SSR via an assist. This workflow is much nicer than the default available via `coc-rust-analyzer` when iterating to find the proper replacement. As currently implemented, this requires the ssr rule is written as a single line in the comment, and it doesn't require any kind of prefix. Anything which properly parses as a ssr rule will enable the assist. The benefit of requiring the ssr rule be on a single line is it allows for a workflow where the user has several rules written one after the other, possibly to be triggered in order, without having to try to parse multiple lines of text and determine where one rule ends and the next begins. The benefit of not requiring a prefix is less typing :laughing: - plus, I think the chance of something accidentally parsing as an ssr rule is minimal. I think a reasonable extension of this would be to allow either any ssr rule that fits on a single line, or any comment block which in its entirety makes up a single ssr rule (parsing a comment block containing multiple ssr rules and running them all would break the use case that currently works where a user writes multiple ssr rules then runs them each one by one in arbitrary order). I've marked this as a draft because for some reason I am strugging to make the unit tests pass. It does work when I compile rust-analyzer and test it in my editor though, so I'm not sure what is going on. Co-authored-by: Josh Mcguigan <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-31 12:20:02 +0100