8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@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.
There's a tension between keeping a well-architectured minimal
orthogonal set of constructs, and providing convenience functions.
Relieve this pressure by introducing an dedicated module for
non-orthogonal shortcuts.
This is inspired by the django.shortcuts module which serves a similar
purpose architecturally.
8591: Remove SyntaxRewriter usage in insert_use in favor of mutable syntax trees r=matklad a=Veykril
Unfortunately changing `insert_use` to not use `SyntaxRewriter` creates a lot of changes since so much relies on that. But on the other hand this should be the biggest usage of `SyntaxRewriter` I believe.
8638: Remove SyntaxRewriter::from_fn r=Veykril a=Veykril
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8467: Adds impl Deref assist r=jhgg a=jhgg
This PR adds a new `generate_deref` assist that automatically generates a deref impl for a given struct field.
Check out this gif:
--
I have a few Q's:
- [x] Should I write more tests, if so, what precisely should I test for?
- [x] I have an inline question on line 65, can someone provide guidance? :)
- [x] I can implement this for `ast::TupleField` too. But should it be a separate assist fn, or should I try and jam both into the `generate_deref`?
- [x] I want to follow this up with an assist on `impl $0Deref for T {` which would automatically generate a `DerefMut` impl that mirrors the Deref as well, however, I could probably use some pointers on how to do that, since I'll have to reach into the ast of `fn deref` to grab the field that it's referencing for the `DerefMut` impl.
Co-authored-by: jake <jh@discordapp.com>
This adds a "Convert Into to From" assist, useful since clippy has
recently started adding lints on every `Into`.
It covers converting the signature, and converting any `self`/`Self`
references within the body to the correct types.
It does assume that every instance of `Into` can be converted to a
`From`, which I _think_ is the case now. Let me know if there's
something I'm not thinking of and I can try and make it smarter.
8267: Adding gifs and screenshots for features in manual r=matklad a=MozarellaMan
For #6539
This includes most of gif or screenshot examples of most items in the "Features" header. With the exceptions of:
- **On Typing Assists** - couldn't get it to work for a demo, I'm probably missing something?
- **Structural search and replace** - looked to be already a visual example of the feature
- **Workspace symbol** - wasn't sure how best to show this, all of the examples maybe? Also wasn't sure of the best code example to show it off
- **Semantic Syntax Highlighting** - seemed obvious enough to not need a screenshot, but I could easily add this
All the gifs/pngs are hosted in this [comment](https://github.com/rust-analyzer/rust-analyzer/issues/6539#issuecomment-809574840). Please let me know if any of them aren't suitable (and why) and I'll improve it! Or if you don't like the theme/font
Co-authored-by: Ayomide Bamidele <48062697+MozarellaMan@users.noreply.github.com>
By including the crate itself, we make the resulting set closed with
respect to `transitve_reveres_dependencies` operation, as it becomes a
proper transitive closure. This just feels more proper and mathy.
And, indeed, this actually allows us to simplify call sites somewhat.
8021: Enable searching for builtin types r=matklad a=Veykril
Not too sure how useful this is for reference search overall, but for completeness sake it should be there
Also enables document highlighting for them.
8022: some clippy::performance fixes r=matklad a=matthiaskrgr
use vec![] instead of Vec::new() + push()
avoid redundant clones
use chars instead of &str for single char patterns in ends_with() and starts_with()
allocate some Vecs with capacity to avoid unnecessary resizing
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
7657: utf8 r=matklad a=matklad
- Prepare for utf-8 offsets
- reduce code duplication in tests
- Make utf8 default, implement utf16 in terms of it
- Make it easy to add additional context for offset conversion
- Implement utf8 offsets
closes#7453
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
