aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_assists
Commit message (Collapse)AuthorAgeFilesLines
...
* Align grammar for record patterns and literalsAleksey Kladov2020-04-111-19/+13
| | | | | | The grammar now looks like this [name_ref :] pat
* Merge #3925bors[bot]2020-04-113-0/+247
|\ | | | | | | | | | | | | | | | | | | 3925: Implement assist "Reorder field names" r=matklad a=geoffreycopin This PR implements the "Reorder record fields" assist as discussed in issue #3821 . Adding a `RecordFieldPat` variant to the `Pat` enum seemed like the easiest way to handle the `RecordPat` children as a single sequence of elements, maybe there is a better way ? Co-authored-by: Geoffrey Copin <[email protected]>
| * Generate docGeoffrey Copin2020-04-111-0/+15
| |
| * Fix doc testsGeoffrey Copin2020-04-111-2/+1
| |
| * Add documentation commentGeoffrey Copin2020-04-111-0/+16
| |
| * Avoid adding a RecordFieldPat variant to the Pat enumGeoffrey Copin2020-04-111-39/+47
| |
| * Remove Option unwrapingGeoffrey Copin2020-04-111-3/+3
| |
| * Implement assist "Reorder field names"Geoffrey Copin2020-04-092-0/+209
| |
* | Change missing impl assist to use todo!() instead of unimplemented()Chris Hopman2020-04-102-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html) Rust documentation provides further clarification: > The difference between unimplemented! and todo! is that while todo! > conveys an intent of implementing the functionality later and the > message is "not yet implemented", unimplemented! makes no such claims. todo!() seems more appropriate for assists that insert missing impls.
* | Rename some tokensAleksey Kladov2020-04-101-1/+2
| |
* | Scale token generation backAleksey Kladov2020-04-102-3/+2
| |
* | Convert more tokensAleksey Kladov2020-04-101-2/+2
| |
* | Curley tokensAleksey Kladov2020-04-101-2/+2
| |
* | Semicolon tokenAleksey Kladov2020-04-101-1/+1
|/
* Simpler acessors for keywordsAleksey Kladov2020-04-091-1/+1
|
* Be consistent about token accesorsAleksey Kladov2020-04-092-2/+2
|
* Add _token suffix to token accessorsAleksey Kladov2020-04-094-5/+5
| | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
* Scale back to only two traitsAleksey Kladov2020-04-091-2/+2
|
* Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-094-8/+9
|
* Fix add missing items assist orderAleksey Kladov2020-04-091-2/+4
| | | | closes #3904
* Check for eprintln on CIAleksey Kladov2020-04-061-0/+5
|
* Merge #3746bors[bot]2020-04-033-0/+817
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3746: Add create_function assist r=flodiebold a=TimoFreiberg The function part of #3639, creating methods will come later - [X] Function arguments - [X] Function call arguments - [x] Method call arguments - [x] Literal arguments - [x] Variable reference arguments - [X] Migrate to `ast::make` API Done, but there are some ugly spots. Issues to handle in another PR: - function reference arguments: Their type isn't printed properly right now. The "insert explicit type" assist has the same issue and this is probably a relatively rare usecase. - generating proper names for all kinds of argument expressions (if, loop, ...?) Without this, it's totally possible for the assist to generate invalid argument names. I think the assist it's already helpful enough to be shipped as it is, at least for me the main usecase involves passing in named references. Besides, the Rust tooling ecosystem is immature enough that some janky behaviour in a new assist probably won't scare anyone off. - select the generated placeholder body so it's a bit easier to overwrite it - create method (`self.foo<|>(..)` or `some_foo.foo<|>(..)`) instead of create_function. The main difference would be finding (or creating) the impl block and inserting the `self` argument correctly - more specific default arg names for literals. So far, every generated argument whose name can't be taken from the call site is called `arg` (with a number suffix if necessary). - creating functions in another module of the same crate. E.g. when typing `some_mod::foo<|>(...)` when in `lib.rs`, I'd want to have `foo` generated in `some_mod.rs` and jump there. Issues: the mod could exist in `some_mod.rs`, in `lib.rs` as `mod some_mod`, or inside another mod but be imported via `use other_mod::some_mod`. - refer to arguments of the generated function with a qualified path if the types aren't imported yet (alternative: run autoimport. i think starting with a qualified path is cleaner and there's already an assist to replace a qualified path with an import and an unqualified path) - add type arguments of the arguments to the generated function - Autocomplete functions with information from unresolved calls (see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605281323) Issues: see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605282542. The unresolved call could be anywhere. But just offering this autocompletion for unresolved calls in the same module would already be cool. Co-authored-by: Timo Freiberg <[email protected]>
| * Use ast::make API in add_function assistTimo Freiberg2020-04-011-67/+48
| |
| * Add create_function assistTimo Freiberg2020-04-013-0/+836
| |
* | Merge #3814bors[bot]2020-04-032-0/+208
|\ \ | |/ |/| | | | | | | | | | | | | | | 3814: Add impl From for enum variant assist r=flodiebold a=mattyhall Basically adds a From impl for tuple enum variants with one field. It was recommended to me on the zulip to maybe try using the trait solver, but I had trouble with that as, although it could resolve the trait impl, it couldn't resolve the variable unambiguously in real use. I'm also unsure of how it would work if there were already multiple From impls to resolve - I can't see a way we could get more than one solution to my query. Fixes #3766 Co-authored-by: Matthew Hall <[email protected]>
| * Cleanup checking for existing impls in impl From assistMatthew Hall2020-04-021-15/+3
| | | | | | | | | | Use the trait solver to check if there's an existing implementation of From<type_in_enum_variant> for the enum.
| * Add impl From for enum variant assistMatthew Hall2020-04-012-0/+220
| | | | | | | | | | | | Basically adds a From impl for tuple enum variants with one field. Added to cover the fairly common case of implementing your own Error that can be created from another one, although other use cases exist.
* | When adding match arm, don't let the floating commaAleksey Kladov2020-03-311-5/+25
| |
* | Use IntoIterAleksey Kladov2020-03-301-2/+1
| |
* | Remove "TODO" in comment in testMatthew Hall2020-03-281-4/+4
| |
* | Append new match arms rather than replacing all of themMatthew Hall2020-03-281-5/+68
|/ | | | This means we now retain comments when filling in match arms.
* Start stdxAleksey Kladov2020-03-285-39/+31
| | | | This crate will hold everything to small to be worth publishing
* Fix merge-imports assist for wildcard importsPiotr Szpetkowski2020-03-271-0/+28
|
* Fix assist descriptionAleksey Kladov2020-03-271-4/+8
|
* Merge #3742bors[bot]2020-03-273-0/+136
|\ | | | | | | | | | | | | | | | | | | | | 3742: Replace if with if-let r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Replace if with if-letAleksey Kladov2020-03-273-0/+136
| |
* | Merge #3741bors[bot]2020-03-271-1/+1
|\| | | | | | | | | | | | | | | | | | | | | 3741: More general ctor for ifs r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * More general ctor for ifsAleksey Kladov2020-03-271-1/+1
| |
* | Merge #3732bors[bot]2020-03-263-0/+203
|\ \ | |/ |/| | | | | | | | | | | 3732: Assist: replace unwrap with match r=matklad a=unrealhoang attempt on #3669 Co-authored-by: Unreal Hoang <[email protected]>
| * Assist: replace unwrap with matchUnreal Hoang2020-03-263-0/+203
| |
* | Get rid of ItemOrMacroAleksey Kladov2020-03-261-2/+2
| |
* | Fix add visibility false-positiveAleksey Kladov2020-03-252-12/+29
|/
* Merge #3708bors[bot]2020-03-243-38/+83
|\ | | | | | | | | | | | | | | | | | | | | 3708: Generalise syntax rewriting infrastructure to allow removal of nodes r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Generalise syntax rewriting infrastructure to allow removal of nodesAleksey Kladov2020-03-243-38/+65
| |
| * Add a testAleksey Kladov2020-03-231-0/+18
| |
* | Merge #3705bors[bot]2020-03-241-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3705: Align naming r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Align namingAleksey Kladov2020-03-241-1/+1
| | |
* | | Merge #3700bors[bot]2020-03-242-47/+47
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 3700: fill match arms with empty block rather than unit tuple r=matklad a=JoshMcguigan As requested by @Veetaha in #3689 and #3687, this modifies the fill match arms assist to create match arms as an empty block `{}` rather than a unit tuple `()`. In one test I left one of the pre-existing match arms as a unit tuple, and added a body to another match arm, to demonstrate that the contents of existing match arms persist. Co-authored-by: Josh Mcguigan <[email protected]>
| * | fill match arms with empty block rather than unit tupleJosh Mcguigan2020-03-242-47/+47
| | |
* | | Add a testKirill Bulatov2020-03-242-9/+45
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-30 20:04:22 +0000