8767: implement range formatting r=matklad a=euclio
Fixes#7580.
This PR implements the `textDocument/rangeFormatting` request using `rustfmt`'s `--file-lines` option.
Still needs some tests. What I want to know is how I should handle the instability of the `--file-lines` option. It's still unstable in rustfmt, so it's only available on nightly, and needs a special flag to enable. Is there a way for `rust-analyzer` to detect if it's using nightly rustfmt, or for users to opt-in?
Co-authored-by: Andy Russell <arussell123@gmail.com>
8873: Implement import-granularity guessing r=matklad a=Veykril
This renames our `MergeBehavior` to `ImportGranularity` as rustfmt has it as the purpose of them are basically the same. `ImportGranularity::Preserve` currently has no specific purpose for us as we don't have an organize imports assist yet, so it currently acts the same as `ImportGranularity::Item`.
We now try to guess the import style on a per file basis and fall back to the user granularity setting if the file has no specific style yet or where it is ambiguous. This can be turned off by setting `import.enforceGranularity` to `true`.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8870
Co-authored-by: Lukas Tobias Wirth <lukastw97@gmail.com>
The new extension allows filtering of workspace symbool lookup
results by search scope or search kind.
Filtering can be configured in 3 different ways:
- The '#' or '*' markers can be added inline with the symbol lookup
query.
The '#' marker means symbols should be looked up in the current
workspace and any dependencies. If not specified, only current
workspace is considered.
The '*' marker means all kinds of symbols should be looked up
(types, functions, etc). If not specified, only type symbols are
returned.
- Each LSP request can take an optional search_scope or search_kind
argument query parameter.
- Finally there are 2 global config options that can be set for all
requests served by the active RA instance.
Add support for setting the global config options to the VSCode
extension.
The extension does not use the per-request way, but it's useful for
other IDEs.
The latest version of VSCode filters out the inline markers, so
currently the only reasonable way to use the new functionality is
via the global config.
8795: Allow semantic tokens for strings to be disabled r=matklad a=djrenren
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7111
Pretty straightforward change, but open to any suggestions if there's a more recommended testing strategy than what I went with.
Co-authored-by: John Renner <john@jrenner.net>
8482: Mention how to customize unsafe operation styles r=matklad a=danielzfranklin
I was confused about how to do this, so I filed #8474. I apologize for initially filing this incorrectly and spamming people.
Co-authored-by: Daniel Franklin <daniel@danielzfranklin.org>
* don't feel obliged to quickly review every PR assigned to you
* so that other folks can notify you about interesting PRs without
thinking to much about creating additional work for you
8510: Move cursor position when using item movers r=jonas-schievink a=jonas-schievink
This updates the cursor position when moving items around to stay in the same location within the moved node.
I changed the `moveItem` response to `SnippetTextEdit[]`, since that made more sense to me (the file was ignored by the client anyways, since the edits always apply to the current document). It also matches `onEnter`, which seems logical to me, but please let me know if this doesn't make sense.
There's still a bug in the client-side snippet code that will cause the cursor position to be slightly off when moving parameters in the same line (presumably we don't track the column correctly after deleting `$0`). Not really sure how to fix that immediately, but this PR should already be an improvement despite that bug.
8533: Fix typo in style guide r=jonas-schievink a=jonas-schievink
Fixes bold text rendering
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8432: decl_check: consider outer scopes' allows r=jonas-schievink a=lf-
Fix#8417. Also makes it less noisy about no_mangle annotated stuff the
user can do nothing about.
Note: this still is broken with bitfield! macros. A repro in an ignore
test is included here. I believe this bug is elsewhere, and I don't
think I can work around it here.
I would like help filing the remaining bug, as it does actually affect
users, but I don't know how to describe the behaviour (or even if it
is unintended).
Co-authored-by: Jade <software@lfcode.ca>
Fix#8417. Also makes it less noisy about no_mangle annotated stuff the
user can do nothing about.
Note: this still is broken with bitfield! macros. A repro in an ignore
test is included here. I believe this bug is elsewhere, and I don't
think I can work around it here.
8136: Introduce QuantifiedWhereClause and DynTy analogous to Chalk r=flodiebold a=flodiebold
This introduces a bunch of new binders in lots of places, which we have to be careful about, but we had to add them at some point. There's a lot of skipping of the binders; once we're done with the Chalk move, we should review the remaining ones.
8146: Document patch policy r=matklad a=matklad
bors r+
🤖
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
7891: Improve handling of rustc_private r=matklad a=DJMcNab
This PR changes how `rust-analyzer` handles `rustc_private`. In particular, packages now must opt-in to using `rustc_private` in `Cargo.toml`, by adding:
```toml
[package.metadata.rust-analyzer]
rustc_private=true
```
This means that depending on crates which also use `rustc_private` will be significantly improved, since their dependencies on the `rustc_private` crates will be resolved properly.
A similar approach could be used in #6714 to allow annotating that your package uses the `test` crate, although I have not yet handled that in this PR.
Additionally, we now only index the crates which are transitive dependencies of `rustc_driver` in the `rustcSource` directory. This should not cause any change in behaviour when using `rustcSource: "discover"`, as the source used then will only be a partial clone. However, if `rustcSource` pointing at a local checkout of rustc, this should significantly improve the memory usage and lower indexing time. This is because we avoids indexing all crates in `src/tools/`, which includes `rust-analyzer` itself.
Furthermore, we also prefer named dependencies over dependencies from `rustcSource`. This ensures that feature resolution for crates which are depended on by both `rustc` and your crate uses the correct set for analysing your crate.
See also [introductory zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Fixed.20crate.20graphs.20and.20optional.20builtin.20crates/near/229086673)
I have tested this in [priroda](https://github.com/oli-obk/priroda/), and it provides a significant improvement to the development experience (once I give `miri` the required data in `Cargo.toml`)
Todo:
- [ ] Documentation
This is ready to review, and I will add documentation if this would be accepted (or if I get time to do so anyway)
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
7643: Automatically detect the rustc-src directory (fixes#3517) r=matklad a=bnjbvr
If the configured rustcSource was not set, then try to automatically
detect a source for the sysroot rustc directory.
I wasn't sure how to do it in the case of the project.json file, though.
7663: Tolerate spaces in nix binary patching r=matklad a=CertainLach
If path to original file contains space (I.e on code insiders, where
default data directory is ~/Code - Insiders/), then there is syntax
error evaluating src arg.
Instead pass path as str, and coerce to path back in nix expression
Co-authored-by: Benjamin Bouvier <public@benj.me>
Co-authored-by: Yaroslav Bolyukin <iam@lach.pw>
`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.
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
7457: Add no-buffering file logging and wait for a debugger option. r=vsrs a=vsrs
Adds two command line flags: `--no-buffering` and `--wait-dbg`.
Not sure if someone else needs this, but personally I found both flags extremely useful trying to figure out why RA does not work with Visual Studio. Or better to say why Visual Studio does not work with RA.
Co-authored-by: vsrs <vit@conrlab.com>
Rather than eagerly converting JSON, we losslessly keep it as is, and
change the shape of user-submitted data at the last moment.
This also allows us to remove a bunch of wrong Defaults
7068: Add VSCode command to view the hir of a function body r=theotherphil a=theotherphil
Will fix https://github.com/rust-analyzer/rust-analyzer/issues/7061. Very rough initial version just to work out where I needed to wire everything up.
@matklad would you be happy merging a hir visualiser of some kind? If so, do you have any thoughts on what you'd like it show, and how?
I've spent very little time on this thus far, so I'm fine with throwing away the contents of this PR, but I want to avoid taking the time to make this more polished/interactive/useful only to discover that no-one else has any interest in this functionality.
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
Use two consecutive newlines (`\n\n`) to actually continue text on a
new line.
Use proper markup to reference related settings.
Consistently format references to files, editor commands, command line
arguments, files, etc. as `code`.
Fix typos, add missing full-stops, add missing default values.
derive(Clone, Copy) reads better than derive(Copy, Clone).
However, we preserve the reverse ordering in the lookup text for
sorting purposes. That way, it's convenient to type just `Ord` to
derive everything.
6325: Add generated diagnostic docs to the manual r=matklad a=flodiebold
It seemed that we're not actually including the generated diagnostic docs anywhere yet? So I added something to the manual. This is completely untested though.
6327: Update debugging.md r=matklad a=stanciuadrian
`on_task` is no longer there.
I have used `on_request` instead.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Adrian Stanciu <stanciu.adrian@gmail.com>
I've noticed that a significant fraction of issues are inert.
They are valid, acknowledged and useful, but effectively can't be
fixed for variety of reasons (no reproduction, dependencies on some
other issues, no review capacity, etc).
Marking issues that can be fixed by just applying some elbow grease
seems useful!
5879: Update mentions of 'ra_vfs' in architecture doc r=matklad a=rherrmann
Adjust the paragraph about `ra_vfs` to point to the `vfs` crate that is used now.
Co-authored-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
5004: Fix panic in split/merge import assists r=matklad a=lnicola
Fixes#4368#4905
Not sure if this is the best solution here. Maybe the `make` functions should be fallible? We generally seem to be playing whack-a-mole with panics in assists, although most of them are `unwrap`s in the assist code.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4580: Fix invoking cargo without consulting CARGO env var or standard installation paths r=matklad a=Veetaha
Followup for #4329
The pr essentially fixes [this bug](https://youtu.be/EzQ7YIIo1rY?t=2189)
cc @lefticus
Co-authored-by: veetaha <veetaha2@gmail.com>
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
4640: Add `inRustProject` when-clause for commands in vscode r=vsrs a=vsrs
At the moment all rust-analyzer commands always visible in the command palette, even if there is no rust project opened.
This PR adds special [when-clause](https://code.visualstudio.com/docs/getstarted/keybindings#_when-clause-contexts) context. This context also might be used in key bindings.
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
4536: Fix names of launch configuration in dev docs r=kjeremy a=kuy
Follows renaming of launch configurations in 80a42a0628
Co-authored-by: Yuki Kodama <endflow.net@gmail.com>
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 <lnicola@dend.ro>
Co-authored-by: Jacob Greenfield <jacob@jacobgreenfield.me>
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 <timo.freiberg@gmail.com>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Leander Tentrup <ltentrup@users.noreply.github.com>
* 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 <copin.geoffrey@gmail.com>
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.
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 <timo.freiberg@gmail.com>
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 <joshmcg88@gmail.com>
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
The new name seems much simpler and it doesn't limit
this config value only to downloading the server binary.
Thus we wouldn't need to create another config
properties to handle other downloads whatsoever.
Anyway, I believe (heuristically) that most of the users
would want to set "askBeforeDownload": false once
and never bother clicking on the notification again
(because otherwise there is no big point in installing rust-analyzer if it cannot install the server)
3053: Feature: downloading lsp server from GitHub r=matklad a=Veetaha
This is currently very WIP, I may need to change this and that, add "download language server command", logging stuff (for future bug reports), etc., but it already works.
Also didn't test this on windows yet and mac (don't have the latter)
The quirks:
* Downloaded binary doesn't have executable permissions by default, that's why we ~~`chmod 111`~~ (**[UPD]** `chmod 755` as per @lnicola [suggestion](https://github.com/rust-analyzer/rust-analyzer/pull/3053#discussion_r376694456)) for it.
* To remove installed binary run `rm /${HOME}/.config/Code/User/globalStorage/matklad.rust-analyzer/ra_lsp_server-linux`, ~~note that `-f` flag is necessary, because of `111` permissions (I think this should be changed)~~ (**[UPD]** --force is no longer needed due to 755 permissions).
I also tried to keep things simple and not to use too many dependencies, all the ones added have 0 dependencies, (`ts-not-nil` is my personal npm package, that imitates `unwrap()` in TypeScript)
**[UPD]** I reduced throttle latency of progress indicator to 200ms for smoother UX
// TODO:
- [x] ~~Add `Rust Analyzer: Download latest language server` vscode command.~~ **[UPD]**: having reviewed the code and estimated available options I concluded that this feature requires too many code changes, I'd like to extract this into a separate PR after we merge this one.
- [x] Add some logging for future debugging
- [x] ~~Gracefully handle the case when language server is not available (e.g. no internet connection, user explicitly rejected the download, etc.)~~ **[UPD]** Decided to postpone better implementation of graceful degradation logic as per [conversation](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Deployment.20and.20installation/near/187758550).
Demo (**[UPD]** this is a bit outdated, but still mainly reflects the feature):
Related issue: #2988#3007
Co-authored-by: Veetaha <gerzoh1@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
2061: Theme loading and "editor.tokenColorCustomizations" support. r=matklad a=seivan
Fixes: [Issue#1294](https://github.com/rust-analyzer/rust-analyzer/issues/1294#issuecomment-497450325)
TODO:
- [x] Load themes
- [x] Load existing `ralsp`-prefixed overrides from `"workbench.colorCustomizations"`.
- [x] Load overrides from `"editor.tokenColorCustomizations.textMateRules"`.
- [x] Use RA tags to load `vscode.DecorationRenderOptions` (colors) from theme & overrides.
- [x] Map RA tags to common TextMate scopes before loading colors.
- [x] Add default scope mappings in extension.
- [x] Cache mappings between settings updates.
- [x] Add scope mapping configuration manifest in `package.json`
- [x] Load configurable scope mappings from settings.
- [x] Load JSON Scheme for text mate scope rules in settings.
- [x] Update [Readme](https://github.com/seivan/rust-analyzer/blob/feature/themes/docs/user/README.md#settings).
Borrowed the theme loading (`scopes.ts`) from `Tree Sitter` with some modifications to reading `"editor.tokenColorCustomizations"` for merging with loaded themes and had to remove the async portions to be able to load it from settings updates.
~Just a PoC and an idea I toyed around with a lot of room for improvement.~
For starters, certain keywords aren't part of the standard TextMate grammar, so it still reads colors from the `ralsp` prefixed values in `"workbench.colorCustomizations"`.
But I think there's more value making the extension work with existing themes by maping some of the decoration tags to existing key or keys.
<img width="453" alt="Screenshot 2019-11-09 at 17 43 18" src="https://user-images.githubusercontent.com/55424/68531968-71b4e380-0318-11ea-924e-cdbb8d5eae06.png">
<img width="780" alt="Screenshot 2019-11-09 at 17 41 45" src="https://user-images.githubusercontent.com/55424/68531950-4b8f4380-0318-11ea-8f85-24a84efaf23b.png">
<img width="468" alt="Screenshot 2019-11-09 at 17 40 29" src="https://user-images.githubusercontent.com/55424/68531952-51852480-0318-11ea-800a-6ae9215f5368.png">
These will merge with the default ones coming with the extension, so you don't have to implement all of them and works well with overrides defined in settings.
```jsonc
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"scope": "keyword",
"settings": {
"fontStyle": "bold",
}
},
]
},
```
Edit: The idea is to work with 90% of the themes out there by working within existing scopes available that are generally styled. It's not to say I want to erase the custom Rust scopes - those should still remain and eventually worked into a custom grammar bundle for Rust specific themes that target those, I just want to make it work with generic themes offered on the market place for now.
A custom grammar bundle and themes for Rust specific scopes is out of... scope for this PR.
We'll make another round to tackle those issues.
Current fallbacks implemented
```typescript
[
'comment',
[
'comment',
'comment.block',
'comment.line',
'comment.block.documentation'
]
],
['string', ['string']],
['keyword', ['keyword']],
['keyword.control', ['keyword.control', 'keyword', 'keyword.other']],
[
'keyword.unsafe',
['storage.modifier', 'keyword.other', 'keyword.control', 'keyword']
],
['function', ['entity.name.function']],
['parameter', ['variable.parameter']],
['constant', ['constant', 'variable']],
['type', ['entity.name.type']],
['builtin', ['variable.language', 'support.type', 'support.type']],
['text', ['string', 'string.quoted', 'string.regexp']],
['attribute', ['keyword']],
['literal', ['string', 'string.quoted', 'string.regexp']],
['macro', ['support.other']],
['variable', ['variable']],
['variable.mut', ['variable', 'storage.modifier']],
[
'field',
[
'variable.object.property',
'meta.field.declaration',
'meta.definition.property',
'variable.other'
]
],
['module', ['entity.name.section', 'entity.other']]
```
Co-authored-by: Seivan Heidari <seivan.heidari@icloud.com>
