| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
RUST_LOG might be set up for debugging the user's problem, slowing
down rust-analyzer considerably. That's the same reason why rustc uses
RUSTC_LOG.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4333: Update Arch Linux and ALE install instructions r=matklad a=polyzen
Package has been added to the Arch repos:
https://www.archlinux.org/packages/community/x86_64/rust-analyzer/
ALE merged rust-analyzer support:
https://github.com/dense-analysis/ale/commit/70005134e5b2d40d176ee5b851ac64a296b22201
Co-authored-by: Daniel M. Capella <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Package has been added to the Arch repos:
https://www.archlinux.org/packages/community/x86_64/rust-analyzer/
ALE merged rust-analyzer support:
https://github.com/dense-analysis/ale/commit/70005134e5b2d40d176ee5b851ac64a296b22201
|
| |
| |
| | |
CC @Coder-256.
|
|/
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| |/
| |
| | |
Fixed macOS path and converted to a list
|
|/ |
|
|\ |
|
| | |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-621109410
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|/
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
|
|
| |
instead of `~/.cargo/bin`
|
|
|
| |
because it's contained in the dart-analyzer repo.
|
| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
|/ / |
|
| |
| |
| |
| | |
cleanup unavailable configurations/commands
|
| | |
|
| | |
|
| |
| |
| | |
Co-Authored-By: Laurențiu Nicola <[email protected]>
|
| |
| |
| | |
Co-Authored-By: Laurențiu Nicola <[email protected]>
|
|/
|
|
|
| |
* 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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|