aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | chore: swap order of placeholdersGowri2021-02-081-1/+1
| | | | |
| * | | | ci: update relevant test case expected valuesGowri2021-02-071-0/+7
| | | | |
| * | | | fix: add for keyword in completion #7588Gowri2021-02-071-0/+1
| |/ / /
* | | | Merge #7549bors[bot]2021-02-081-5/+73
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7549: Documentation: Explain how initial configuration is sent over LSP and document vim-lsp r=ilya-bobyr a=ilya-bobyr This request contains two related but independent changes. The first explains `rust-analyzer` initial configuration over LSP. The second - adds documentation on `vim-lsp` Vim plugin and provides an example of the initial configuration for `rust-analyzer` when using this particular LSP client. Let me know if you would prefer the changes to be reviewed in two separate pull requests. Co-authored-by: Ilya Bobyr <[email protected]>
| * | | Vim docs: vim-lsp with initial configuration.Ilya Bobyr2021-02-081-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | `vim-lsp` is another popular LSP client for Vim. And, as there is no `rust-analyzer` specific UI, it is non-trivial to figure out how the initial configuration is performed.
| * | | Explain how initial configuration is sent over LSP.Ilya Bobyr2021-02-081-5/+27
|/ / /
* | | Merge #7587bors[bot]2021-02-079-40/+40
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7587: AdtDef -> Adt r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | AdtDef -> AdtAleksey Kladov2021-02-079-40/+40
|/ / /
* | | Merge #7586bors[bot]2021-02-071-1/+9
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7586: Add a section on entry points r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Add a section on entry pointsAleksey Kladov2021-02-071-1/+9
|/ / /
* | | Fixing architecture image on dark themeErick Tovar2021-02-071-1/+1
| | |
* | | Merge #7585bors[bot]2021-02-071-2/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7585: More information for mbe in architecture.md r=edwin0cheng a=edwin0cheng bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * | | Remove redunacnyEdwin Cheng2021-02-071-1/+1
| | | |
| * | | More information for mbeEdwin Cheng2021-02-071-2/+7
| | | |
* | | | Merge #7584bors[bot]2021-02-071-0/+11
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7584: Update architecture.md for mbe and proc-macro r=edwin0cheng a=edwin0cheng Co-authored-by: Edwin Cheng <[email protected]>
| * | | Update architecture.md for mbe and proc-macroEdwin Cheng2021-02-071-0/+11
|/ / /
* | | Merge #7583bors[bot]2021-02-061-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7583: Update architecture.md r=bjorn3 a=aTuck Typo Co-authored-by: Adam Tuck <[email protected]>
| * | | Update architecture.mdAdam Tuck2021-02-061-1/+1
|/ / / | | | | | | Typo
* | | Merge #7578bors[bot]2021-02-062-1/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7578: Add a semantic token type for char literals r=Veykril a=petr-tik Fixes #7530 The LSP spec doesn't recognise character literals, so had to extend the suported types to our own custom type Co-authored-by: petr-tik <[email protected]>
| * | | Add a semantic token type for char literalspetr-tik2021-02-052-1/+3
|/ / / | | | | | | | | | | | | The LSP spec doesn't recognise character literals, so had to extend the suported types to our own custom type
* | | Merge #7577bors[bot]2021-02-051-10/+10
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 7577: cargo update r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | cargo updatekjeremy2021-02-051-10/+10
| | |
* | | Merge #7576bors[bot]2021-02-051-3/+3
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | 7576: Fix resolveCodeAction trying to edit files before creating them r=Veykril a=Veykril Fixes #7208 bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * | Fix resolveCodeAction trying to edit files before creating themLukas Wirth2021-02-051-3/+3
| | |
* | | Merge #7575bors[bot]2021-02-052-7/+19
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7575: Fix resolution of `self` module within blocks r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | Test `super` resolution tooJonas Schievink2021-02-051-0/+2
| | | |
| * | | Fix resolution of `self` module within blocksJonas Schievink2021-02-052-7/+17
|/ / /
* | | Merge #7572bors[bot]2021-02-053-29/+30
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7572: Add `find_or_create_impl_block` to assist utils r=matklad a=yoshuawuyts This is another continuation of https://github.com/rust-analyzer/rust-analyzer/pull/7562, introducing a small util to either find an `impl` block, or create a new one if none exists. I copied this code from the `generate_new` assist into https://github.com/rust-analyzer/rust-analyzer/pull/7562, and this unifies both into a helper. It doesn't feel super polished in its current state, but my hope is that this is enough of a starting point that it can be expanded on later. For example something that would be useful would be a flag which either returns the index of the start of the block, or the end of the block. Anyway, I hope this is useful. Thanks! Co-authored-by: Yoshua Wuyts <[email protected]>
| * | Add `find_or_create_impl_block` to assist utilsYoshua Wuyts2021-02-053-29/+30
| | |
* | | Merge #7573bors[bot]2021-02-052-3/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7573: Do not overwrite lock file r=kjeremy a=kjeremy Use `npm ci` instead of `npm install`. `npm install` will overwrite the lock file if you have a newer npm version than the one that generated the package-lock.json Co-authored-by: kjeremy <[email protected]>
| * | | Do not overwrite lock filekjeremy2021-02-052-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Use `npm ci` instead of `npm install`. `npm install` will overwrite the lock file if you have a newer npm version than the one that generated the package-lock.json
* | | | Merge #7574bors[bot]2021-02-057-17/+8
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7574: Remove various redundant clones r=kjeremy a=yoshuawuyts I noticed when running clippy through RA that there are a few instances where `clone` is called where it's not actually needed. I figured a small patch to remove these might be welcome here. Thanks! Co-authored-by: Yoshua Wuyts <[email protected]>
| * | | Remove redundant clonesYoshua Wuyts2021-02-057-17/+8
| |/ /
* | | Merge #7505bors[bot]2021-02-051-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7505: Widen Highlights root range to covering element r=Veykril a=Veykril There have been a few issues about/containing spurious syntax highlighting panics, which all seem to come from the `rust_analyzer::handlers::handle_semantic_tokens_range` request, which I believe this to be the cause of as the text range we want to highlight here is currently potentially smaller than that of the covering element, so we might highlight something that is inside the covering element, but outside of the text range we wish to highlight causing the assert to fail. Unfortunately this isn't really easy to test since I have yet to find a reproducible cause(#7504 doesn't work for me cause I can't seem to checkout the given commit). See #7504, #7298, #7299 and #7416, all of those contain an assertion failure in syntax highlighting, but only in the range request. Co-authored-by: Lukas Wirth <[email protected]>
| * | | Increase Highlights highlight range to covering elementLukas Wirth2021-02-041-1/+1
| | | |
| | | |
| \ \ \
*-. \ \ \ Merge #7570 #7571bors[bot]2021-02-056-165/+164
|\ \ \ \ \ | |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7570: Add doc gen to the `generate_enum_match_method` assist r=yoshuawuyts a=yoshuawuyts Implements a small extension to https://github.com/rust-analyzer/rust-analyzer/pull/7562, generating default comments. I wasn't sure if this would fit the goals of Rust-Analyzer, so I chose to split it into a separate PR. This is especially useful when writing code in a codebase which uses `#![warn(missing_docs)]` lint, as many production-grade libraries do. The comments we're generating here are similar to the ones found on [`Option::is_some`](https://doc.rust-lang.org/std/option/enum.Option.html#method.is_some) and [`Result::is_err`](https://doc.rust-lang.org/std/result/enum.Result.html#method.is_err). I briefly considered only generating these for `pub` types, but they seem small and unobtrusive enough that they're probably useful in the general case. Thanks! ## Example __input__ ```rust pub(crate) enum Variant { Undefined, Minor, // cursor here Major, } ``` __output__ ```rust pub(crate) enum Variant { Undefined, Minor, Major, } impl Variant { /// Returns `true` if the variant is [`Minor`]. pub(crate) fn is_minor(&self) -> bool { matches!(self, Self::Minor) } } ``` ## Future Directions This opens up the path to adding an assist for generating these comments on existing `is_` methods. This would make it both easy to document new code, and update existing code with documentation. 7571: Cleanup decl_check r=Veykril a=Veykril bors r+ Co-authored-by: Yoshua Wuyts <[email protected]> Co-authored-by: Lukas Wirth <[email protected]>
| | * | | Cleanup decl_checkLukas Wirth2021-02-054-164/+154
| | | | |
| * | | | Add doc gen to the `generate_enum_match_method` assistYoshua Wuyts2021-02-052-1/+10
| | | | |
* | | | | Merge #7569bors[bot]2021-02-051-0/+8
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7569: Add howtos r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | Add howtosAleksey Kladov2021-02-051-0/+8
| | | | | |
* | | | | | Merge #7562bors[bot]2021-02-055-64/+317
|\ \ \ \ \ \ | |/ / / / / |/| / / / / | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7562: add `generate_enum_match` assist r=matklad a=yoshuawuyts This adds a `generate_enum_match` assist, which generates `is_` variants for enums (e.g. `Option::{is_none,is_some}` in std). This is my first attempt at contributing to Rust-Analyzer, so I'm not sure if I've gotten everything right. Thanks! ## Example **Input** ```rust pub(crate) enum Variant { Undefined, Minor, // cursor here Major, } ``` **Output** ```rust pub(crate) enum Variant { Undefined, Minor, Major, } impl Variant { pub(crate) fn is_minor(&self) -> bool { matches!(self, Self::Minor) } } ``` ## Future Directions I made this as a stepping stone for some of the more involved refactors (e.g. #5944). I'm not sure yet how to create, use, and test `window.showQuickPick`-based asssists in RA. But once that's possible, it'd probably be nice to be able to generate match methods in bulk through the quickpick UI rather than one-by-one: ``` [x] Select enum members to generate methods for. (3 selected) [ OK ] --------------------------------------------------------------------------- [x] Undefined [x] Minor [x] Major ``` Co-authored-by: Yoshua Wuyts <[email protected]> Co-authored-by: Yoshua Wuyts <[email protected]>
| * | | | Move `find_struct_impl` to assist utilsYoshua Wuyts2021-02-053-154/+85
| | | | |
| * | | | add `generate-enum-match` assistYoshua Wuyts2021-02-053-0/+322
| | | | |
* | | | | Merge #7568bors[bot]2021-02-051-2/+5
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7568: Fix merging of `segment_index` in path resolution r=jonas-schievink a=jonas-schievink This caused associated item lookup to fail when modifying `resolver.rs` to handle block expressions with inner items. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | | | Fix merging of `segment_index` in path resolutionJonas Schievink2021-02-051-2/+5
| | |/ / / | |/| | |
* | | | | Merge #7567bors[bot]2021-02-051-18/+16
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7567: Remove unnecessary allocs in case_conv r=Veykril a=Veykril and some replace unwraps bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * | | | Remove unnecessary allocs in case_convLukas Wirth2021-02-051-18/+16
|/ / / /
* | | | Merge #7535bors[bot]2021-02-054-1/+2189
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7535: Extract function assist r=cpud36 a=cpud36 This PR adds `extract function/method` assist. closes #5409. # Supported features Assist should support extracting from expressions(`1`, `2 + 2`, `loop { }`) and from a series of statements, e.g.: ```rust foo(); $0bar(); baz();$0 quix(); ``` Assist also supports extracting parameters, like: ```rust fn foo() -> i32 { let n = 1; $0n + 1$0 } // - fn foo() -> i32 { let n = 1; fun_name(n) } fn fun_name(n: i32) -> i32 { n + 1 } ``` Extracting methods also generally works. Assist allows referencing outer variables, both mutably and immutably, and handles handles access to variables local to extracted function: ```rust fn foo() { let mut n = 1; let mut m = 2; let mut moved_v = Vec::new(); let mut ref_mut_v = Vec::new(); $0 n += 1; let k = 1; moved_v.push(n); let r = &mut m; ref_mut_v.push(*r); let h = 3; $0 n = ref_mut_v.len() + k; n -= h + m; } // - fn foo() { let mut n = 1; let mut m = 2; let mut moved_v = Vec::new(); let mut ref_mut_v = Vec::new(); let (k, h) = fun_name(&mut n, moved_v, &mut m, &mut ref_mut_v); n = ref_mut_v.len() + k; n -= h + m; } fn fun_name(n: &mut i32, mut moved_v: Vec<i32>, m: &mut i32, ref_mut_v: &mut Vec<i32>) -> (i32, i32) { *n += 1; let k = 1; moved_v.push(*n); let r = m; ref_mut_v.push(*r); let h = 3; (k, h) } ``` So we handle both input and output paramters # Showcase ![extract_cursor_in_range_3](https://user-images.githubusercontent.com/4218373/106980190-c9870800-6770-11eb-83d9-3d36b2550ff6.gif) ![fill_match_arms_discard_wildcard](https://user-images.githubusercontent.com/4218373/106980197-cbe96200-6770-11eb-96b0-14c27894fac0.gif) ![ide_db_helpers_handle_kind](https://user-images.githubusercontent.com/4218373/106980201-cdb32580-6770-11eb-9e6e-6ac8155d65ac.gif) ![ide_db_imports_location_local_query](https://user-images.githubusercontent.com/4218373/106980205-cf7ce900-6770-11eb-8516-653c8fcca807.gif) # Working with non-`Copy` types Consider the following example: ```rust fn foo() { let v = Vec::new(); $0 let n = v.len(); $0 let is_empty = v.is_empty(); } ``` `v` must be a parameter to extracted function. The question is, what type should it have. It could be `v: Vec<i32>`, or `v: &Vec<i32>`. The former is incorrect for `Vec<i32>`, but the later is silly for `i32`. To resolve this we need to know if the type implements `Copy` trait. I didn't find any api available from assists to query this. `hir_ty::method_resolution::implements` seems relevant, but is isn't publicly re-exported from `hir`. # Star(`*`) token and pointer dereference If I understand correctly, in order to create expression like `*p`, one should use `ast::make::expr_prefix(T![*], ...)`, which in turn calls `token(T![*])`. `token` does not have star in `tokens::SOURCE_FILE`, so this panics. I had to add `*` to `SOURCE_FILE` to make it work. Correct me if this is not intended way to do this. # Lowering access `value -> mut ref -> shared ref` Consider the following example: ```rust fn foo() { let v = Vec::new(); $0 let n = v.len(); $0 } ``` `v` is not used after extracted function body, so both `v: &Vec<i32>` and `v: Vec<i32>` would work. Currently the later would be chosen. We can however check the body of extracted function and conclude that `v: &Vec<i32>` is sufficient. Using `v: &Vec<i32>`(that is a minimal required access level) might be a better default. I am unsure. # Cleanup The assist seems to be reasonably handling most of common cases. If there are no concerns with code it produces(i.e. with test cases), I will start cleaning up [edit] added showcase Co-authored-by: Vladyslav Katasonov <[email protected]>
| * | | allow extracted body to be indented(dedent it)Vladyslav Katasonov2021-02-051-13/+101
| | | |
| * | | allow transitive `&mut` access for fields in extract_functionVladyslav Katasonov2021-02-051-27/+92
| | | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-11 19:25:58 +0000