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>
8889: internal: Track in-scope derive helpers during nameres r=jonas-schievink a=jonas-schievink
...without using them yet
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8888: fix: fix unresolved attribute fallback again r=jonas-schievink a=jonas-schievink
`ModItem`s are per-file, so we have to track the file if we store them in the crate-level `DefCollector`.
Fixes the remaining issue in https://github.com/rust-analyzer/rust-analyzer/pull/8882#issuecomment-844379170
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8885: internal: greatly simplify eager macro representation r=jonas-schievink a=jonas-schievink
- Share structures with lazy macros, make both use `MacroCallLoc`.
- Remove `intern_eager_expansion`, `EagerCallLoc`, `EagerMacroId`, and *many* matches on `MacroCallId`.
- Make a lot of FIXMEs obsolete since the code no longer distinguishes between eager and lazy macros.
- Add `EagerCallInfo`, which is `Some` for calls to eager macros and holds the argument or expansion result and the included file.
8887: fix: fix derive collection after unresolved attribute fallback r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/pull/8882#issuecomment-844379170
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8884: fix: add_explicit_type produces invalid code on `@` patterns r=Veykril a=iDawer
In
```rust
let name @ () = ();
```
an explicit type should be inserted after the pattern, not just after the name.
`let` statement defined as `LetStmt = Attr* 'let' Pat (':' Type)? '=' initializer:Expr ';'`
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8882: internal: resolve attributes in name resolution (minimal version) r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/pull/7049
This should not have any observable effect, since we don't attempt to expand attribute macros yet, and I have implemented a fallback that treats items with unresolved attributes as if the attribute wasn't there.
Derive helpers are not yet resolved. `#![register_{attr,tool}]` are not yet supported.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7698: Add new LSP extension for workspace symbol lookup r=matklad a=alcroito
As well as all symbol types (functions, modules).
Remove outdated documentation regarding symbol lookup filtering.
Closes#4881
Co-authored-by: alcroito <placinta@gmail.com>
8345: Add pub mod option for UnlinkedFile r=rainy-me a=rainy-me
close#8228
This is a draft that changes `Diagnostic` to contain multiple fixes. Pre analysis is in https://github.com/rust-analyzer/rust-analyzer/issues/8228#issuecomment-812887085 Because this solution is straightforward so I decided to type it out for discussion.
Currently the `check_fix` is not able to test the situation when multiple fixes available. <del>Also because `Insert 'mod x;'` and `Insert 'pub mod x;'` are so similar, I don't know how to test them correctly and want some suggestions.</del>. I added
`check_fixes` to allow checking mutiple possible fixes.
In additional, instead of append after possible existing `mod y`, I think it's possible to Insert `pub mod x;` after `pub mod y`. Should I implement this too?
Co-authored-by: rainy-me <github@rainy.me>
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.
8766: Extract function assist will add async if required r=Veykril a=JamieCunliffe
The extract function assist will check for an AWAIT_EXPR or AWAIT_KW in the body and if found, will add async to the generated function.
closes#8232
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@outlook.com>
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>
