aboutsummaryrefslogtreecommitdiff
path: root/docs/user
Commit message (Collapse)AuthorAgeFilesLines
...
* | Fix Windows server pathLaurențiu Nicola2020-05-061-1/+1
| | | | | | CC @Coder-256.
* | add Ok wrappingBenjamin Coenen2020-05-061-0/+12
|/ | | | Signed-off-by: Benjamin Coenen <[email protected]>
*-. Merge #4306 #4308bors[bot]2020-05-051-1/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4306: Make incremental sync opt-out and fix line index rebuild r=matklad a=lnicola 4308: Update server binary paths in docs r=matklad a=Coder-256 Fixed incorrect macOS path and converted to a list. Also, should the Windows path include `matklad.rust-analyzer`? (I can't check) Co-authored-by: Laurențiu Nicola <[email protected]> Co-authored-by: Jacob Greenfield <[email protected]>
| | * Update server binary pathsJacob Greenfield2020-05-041-1/+5
| |/ | | | | Fixed macOS path and converted to a list
* / [manual] Improve requirements and editor wordingFrancisco Lopes2020-05-041-3/+3
|/
* Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-022-2/+13
|\
| * Add missing members generates indented blocksAleksey Kladov2020-05-021-1/+3
| |
| * Document Gnome Builder supportLaurențiu Nicola2020-05-011-1/+10
| |
* | Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-012-8/+25
|\|
| * Update readme.adochafiz2020-04-301-2/+2
| |
| * Fix typo in language server binary docshafiz2020-04-301-1/+1
| |
| * docs(user): method chaining hints supportHeyward Fann2020-04-301-2/+4
| | | | | | | | https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-621109410
| * Fix Typos on features.mdKENTARO OKUDA2020-04-291-2/+2
| |
| * Fix YouComplteMe instructions linkBoris Staletic2020-04-291-1/+1
| |
| * add ale to the nvim setup section of the readmeSimon Cruanes2020-04-291-0/+15
| |
* | Add unwrap block assist #4156Benjamin Coenen2020-04-291-2/+2
| | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | Add unwrap block assist #4156Benjamin Coenen2020-04-291-0/+18
|/ | | | Signed-off-by: Benjamin Coenen <[email protected]>
* Add missing .Günter Zöchbauer2020-04-261-1/+1
|
* Change install directory suggestion to `~/.local/bin`Günter Zöchbauer2020-04-261-3/+5
| | | instead of `~/.cargo/bin`
* xtask does not need to be installedGünter Zöchbauer2020-04-261-4/+1
| | | because it's contained in the dart-analyzer repo.
* Clarify rust-analyzer binary installGünter Zöchbauer2020-04-261-7/+23
|
*-. Merge #3998 #4006bors[bot]2020-04-241-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3998: Make add_function generate functions in other modules via qualified path r=matklad a=TimoFreiberg Additional feature for #3639 - [x] Add tests for paths with more segments - [x] Make generating the function in another file work - [x] Add `pub` or `pub(crate)` to the generated function if it's generated in a different module - [x] Make the assist jump to the edited file - [x] Enable file support in the `check_assist` helper 4006: Syntax highlighting for format strings r=matklad a=ltentrup I have an implementation for syntax highlighting for format string modifiers `{}`. The first commit refactors the changes in #3826 into a separate struct. The second commit implements the highlighting: first we check in a macro call whether the macro is a format macro from `std`. In this case, we remember the format string node. If we encounter this node during syntax highlighting, we check for the format modifiers `{}` using regular expressions. There are a few places which I am not quite sure: - Is the way I extract the macro names correct? - Is the `HighlightTag::Attribute` suitable for highlighting the `{}`? Let me know what you think, any feedback is welcome! Co-authored-by: Timo Freiberg <[email protected]> Co-authored-by: Leander Tentrup <[email protected]> Co-authored-by: Leander Tentrup <[email protected]>
| * | Make add_function generate functions in other modules via qualified pathTimo Freiberg2020-04-211-2/+2
| | |
* | | Add YouCompleteMe as a LSP option for vim/neovimWeihang Lo2020-04-231-0/+20
|/ /
* | docs(readme): improve user docsHeyward Fann2020-04-211-2/+2
| | | | | | | | cleanup unavailable configurations/commands
* | Move the PATH issue up to the non-editor specific sectionNikolai Morin2020-04-211-1/+3
| |
* | Delete commaNikolai Morin2020-04-211-1/+1
| |
* | Update docs/user/readme.adocNikolai Morin2020-04-211-1/+1
| | | | | | Co-Authored-By: Laurențiu Nicola <[email protected]>
* | Update docs/user/readme.adocNikolai Morin2020-04-211-1/+1
| | | | | | Co-Authored-By: Laurențiu Nicola <[email protected]>
* | More detailed Sublime Text install instructionsNikolai Morin2020-04-211-14/+23
|/ | | | | * People might typically jump directly to their editor and wonder where the part about installing rust-analyzer is – at least I did. I added a link to the relevant section for ST. * Make ST instructions more detailed and user friendly (especially beginners), include troubleshooting tips. * Minor grammar improvements throughout.
* Change add_function assist to use todo!()Timo Freiberg2020-04-131-1/+1
|
* Merge #3925bors[bot]2020-04-111-0/+15
|\ | | | | | | | | | | | | | | | | | | 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
| |
* | Change missing impl assist to use todo!() instead of unimplemented()Chris Hopman2020-04-101-1/+1
|/ | | | | | | | | | | | 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.
* Better Sublime documentationElinvynia2020-04-081-24/+1
|
* Merge #3746bors[bot]2020-04-031-0/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Add create_function assistTimo Freiberg2020-04-011-0/+26
| |
* | vscode: move docks about syntax tree to dev/README.mdveetaha2020-04-021-10/+0
| |
* | vscode: add docs about goto-definition for rust syntax treeveetaha2020-04-021-0/+4
|/
* vscode: add docs about syntax treeveetaha2020-03-311-0/+6
|
* Update docs to mention on WindowsEdwin Cheng2020-03-281-1/+1
|
* Update docs/user/readme.adocAleksey Kladov2020-03-281-1/+1
| | | Co-Authored-By: Laurențiu Nicola <[email protected]>
* Update docs to mention vscode installation path on macOSMariusz Klochowicz2020-03-281-1/+1
|
* Fix assist descriptionAleksey Kladov2020-03-271-1/+1
|
* Merge #3742bors[bot]2020-03-271-0/+23
|\ | | | | | | | | | | | | | | | | | | | | 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-271-0/+23
| |
* | Assist: replace unwrap with matchUnreal Hoang2020-03-261-0/+23
|/
* Updated docsMatt Hooper2020-03-241-0/+2
|
* Merge #3700bors[bot]2020-03-241-2/+2
|\ | | | | | | | | | | | | | | | | | | 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]>
| * update assists docsJosh Mcguigan2020-03-241-2/+2
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 10:17:09 +0000