This also seizes the opportunity to move integer literal parsing to
the syntax crate, were it logically belongs.
Note though that this is still done in an ad hoc manner -- we probably
should split kitchen sink ast::Literal into a separate APIs for
strings, ints, etc
6393: Remove repetitive inlay hints (take 2) r=matklad a=lnicola
6399: Keep generic annotations when qualifying things r=matklad a=Veykril
The `qualify_path` assists currently eats up already annotated generics in all but one cases which can be annoying if one already pre-fills generics of a type before it's been qualified.
Co-authored-by: Matthew Sanetra <matthewsanetra@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6333: Don't interpret type path as part of visibility. r=matklad a=ArifRoktim
This closes#5902.
I only check that the next token isn't equal to `T![:]`, instead of the next two not being equal to `T![::]`. Is that ok?
Co-authored-by: Arif Roktim <arifrroktim@gmail.com>
6172: Add qualify path assist r=matklad a=Veykril
This implements a `qualify_path` assist which works quite similar to the `auto_import` assist but instead of adding imports to the file it well, qualifies the path. This PR also moves out the `AutoImportAssets` struct and functions from `auto_import` into a utils submodule as most of this is now shared between `auto_import` and `qualify_path`.
Changes made to `AutoImportAssets` are solely in its `search_for_imports` function which now takes a prefixed parameter to discern between using `find_use_path_prefixed` and `find_use_path` as the former is the required behavior by `auto_import` and the latter by this assist.
For missing imported traits instead of importing this will qualify the path with a trait cast as in:
```rust
test_mod::TestStruct::TEST_CONST<|>
```
becomes
```rust
<test_mod::TestStruct as test_mod::TestTrait>::TEST_CONST
```
and for trait methods ideally it would do the following:
```rust
let test_struct = test_mod::TestStruct {};
test_struct.test_meth<|>od()
```
becomes
```rust
let test_struct = test_mod::TestStruct {};
test_mod::TestTrait::test_method(&test_struct)
```
Fixes#4124.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6207: Extract ImportAssets out of auto_import r=matklad a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/pull/6172#issuecomment-707182140
I couldn't fully pull out `AssistContext` as `find_node_at_offset_with_descend`: 81fa00c5b5/crates/assists/src/assist_context.rs (L90-L92) requires the `SourceFile` which is private in it and I don't think making it public just for this is the right call?
6224: ⬆️ salsa r=matklad a=matklad
bors r+
🤖
6226: Add reminder to update lsp-extensions.md r=matklad a=matklad
bors r+
🤖
6227: Reduce bors timeout r=matklad a=matklad
bors r+
🤖
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc
Resolves#4598.
After a third try, it finally works. Boy, it appeared tougher than it seemed.
Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?".
Well, the problems with the information provided by `rustc` appeared shortly:
- `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes.
When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`.
Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references.
- Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes.
- Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less
convenient for that matter than `ide` crate.
That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait.
After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics
which look at any `ModuleDef`.
And of course, since I'd added a lot of new functionality, it required extensive testing.
That explains why the diff is so big for a (looking) relatively small feature.
I hope that this PR doesn't only add a small feature, but also creates a base for building another features.
## Example:
P.S. My eyes were bleeding when I had to write the code for the example...
6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj
I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Previously, "find all references" on a variant field wouldn't find any
references outside the defining module. This is because variant fields
were incorrectly assumed to be private, like struct fields without
explicit visibility, but they actually inherit the enum's visibility.
6139: Make find_path_prefixed configurable r=matklad a=Veykril
This makes `find_path_prefixed` more configurable allowing one to choose whether it always returns absolute paths, self-prefixed paths or to ignore local imports when building the path.
The config names are just thrown in here, taking better names if they exist :)
This should fix#6131 as well?
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6111: Add assist for converting the base of integer literals. r=SomeoneToIgnore a=vlakreeh
This PR adds an assist similar to Intellij's [convert number to](https://i.imgur.com/JH6wstP.png). It also does a small refactor to [assists/src/tests.rs](fc34403018/crates/assists/src/tests.rs) to add the ability to specify the resolved assist for a specific action within an assist group.
## Demo
Co-authored-by: vlakreeh <zeb@zebulon.dev>
6019: Remove make::path_from_text r=matklad a=Veykril
This removes the `make::path_from_text` function, which according to a note should've been private. I removed it since it didn't really serve a purpose as it was simply wrapping `make::ast_from_text`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5989: Rewrite import merging r=jonas-schievink a=Veykril
Rewrites how import merging is being handled. It is now a recursive function to properly handle merging of intermediate levels in the import trees. With this ordering the imports is also now possible tho it doesn't quite order it the same way as `rustfmt` does yet, namely it orders lowercase identifiers after uppercase identifiers as that is the standard character order that rust uses. This also fixes a few weird behaviors that were visible in some of the `replace_qualified_name_with_use.rs` tests.
This really took longer than I was hoping for, fighting with import trees is quite the exhausting task 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5955: Remove merge import code duplication r=jonas-schievink a=Veykril
This removes the code duplication caused by #5935, this also allows the assist to merge imports that have equal visibility and prevents merges of unequal visibility. This PR also fixes an iteration mistake in the mentioned PR:
Turns out I made a mistake when writing the `segment_iter` function, I was assuming that the `children` of a path will just be the segments, which is obviously not the case. This also brings insertion order of shorter paths in line with how `rustfmt` orders them.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5940: Implement "Replace `impl Trait` function argument with the named generic" assist. r=matklad a=alekseysidorov
Fixes#5085
Co-authored-by: Aleksei Sidorov <gorthauer87@yandex.ru>
We might want to provide more efficient impls for check if usages
exist, limiting the search, filtering and cancellation, so let's
violate YAGNI a bit here.
5776: Fix eslint errors on .eslintrc.js and rollup.config.js r=matklad a=fuafa
Eslint complains if these two files does not include in the `tsconfig.json`.
```
Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: .eslintrc.js.
The file must be included in at least one of the projects provided.eslint
```
5780: Fixup whitespace when adding missing impl items r=matklad a=jDomantas
Generate properly formatted whitespace when adding impl items - with an empty line between items and removing extra whitespace that often appears at the end.
This is my first time working on rust analyzer so I'm not very familiar with its internal APIs. If there's a better way to do such syntax tree editing I'd be glad to hear it.
Co-authored-by: xiaofa <xiaofalzx@gmail.com>
Co-authored-by: jDomantas <djadenkus@gmail.com>
Conjecture: it's impossible to use hir::Path *correctly* from an IDE.
I am not entirely sure about this, and we might need to add it back at
some point, but I have to arguments that convince me that we probably
won't:
* `hir::Path` has to know about hygiene, which an IDE can't set up
properly.
* `hir::Path` lacks identity, but you actually have to know identity
to resolve it correctly
