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>
6205: Fix iterator hint shortening heuristic r=SomeoneToIgnore a=Veykril
Turns out I made a mistake with the heuristic check which is always true, so all iterators exposed from `core` were shortened, including things like ranges. 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6153: Improve prime_caches and display its progress r=matklad a=jonas-schievink
It now computes the `CrateDefMap` of all crates, which is generally a reasonable approximation for "IDE features ready". There is still some delay after this finishes, I suspect mostly due to impl collection, which takes a while, but this should be an improvement already.
For more accurate progress reports, this topologically sorts all crates before starting this operation. ~~Because that is also the ordering in which parallelization makes sense (which was previously attempted in https://github.com/rust-analyzer/rust-analyzer/pull/3529), I decided to throw that into the mix as well. It still doesn't provide *that* much of a performance boost, but it does scale beyond the current single-core architecture, and adding it was very easy.~~
~~Unfortunately, as written, this will not tell the user which crate is actually causing slowdowns, since the displayed crate is the last one that was *started*, not the one we are currently *blocked* on, but that seems fairly difficult to implement unless I'm missing something.~~
(I have removed rayon for now since it does not work correctly with cancellation.)
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6198: Skip macro matcher fragment name semantic highlighting r=matklad a=Veykril
Implements a small state-machine for macro_rules! highlighting to separate out the matcher part of its rules. This skips semantically highlighting names of metavariables in the matcher and expander. This might even allow for more fun macro highlighting things in the future.
Fixes#4380.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6199: Fix `mut self` not emitting mutable binding on `self` use r=matklad a=Veykril
Prior to this, when `self` in a function is taken by value and bound mutably, its use inside of the method body won't be marked `mutably`.
Fixes#5461
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps
#### Todo
- [ ] Decide if there should be a default keybind or context menu entry
- [x] Figure out how to get the documentation path for methods and other non-top-level defs
- [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR?
- [x] Code organisation
- [x] Tests
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
Return an error with a meaningful message for requests to
`textDocument/rename` if the operation cannot be performed.
Pass errors raised by rename handling code to the LSP runtime.
As a consequence, the VS Code client shows and logs the request
as if a server-side programming error occured.
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/3981
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.
5651: Add track_env_var to the proc macro server r=kjeremy a=lnicola
See https://github.com/rust-lang/rust/pull/74653.
Fixes#6054.
Fixes#5640, maybe.
Should be merged when 1.47 is released.
Proc macros still don't work for me, but it no longer crashes.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
6161: Bump chalk to use latest git to get upstream fix r=jonas-schievink a=Ameobea
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
Co-authored-by: Casey Primozic <me@ameo.link>
6154: Shorten type hints for std::iter Iterators r=SomeoneToIgnore a=Veykril
Fixes#3750.
This re-exports the `hir_expand::name::known` module to be able to fetch the `Iterator` and `iter` names.
I'm not sure if there is anything to do with `Solution::Ambig` in `normalize_trait_assoc_type` or whether discarding those results is always wanted.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Percentage is a UI concern, the physical fact here is fraction. It's
sad that percentage bleeds into the protocol level, we even duplicated
this bad API ourselves!
6158: Fix for negative literals in macros r=matklad a=cutsoy
_This pull request fixes #6028._
When writing `-42.0f32` in Rust, it is usually parsed as two different tokens (a minus operator and a float literal).
But a procedural macro can also generate new tokens, including negative [float literals](https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.f32_suffixed):
```rust
#[proc_macro]
fn example_verbose(input: TokenStream) -> TokenStream {
let literal = Literal::f32_suffixed(-42.0);
quote! { #literal }
}
```
or even shorter
```rust
#[proc_macro]
fn example(input: TokenStream) -> TokenStream {
let literal = -42.0f32;
quote! { #literal }
}
```
Unfortunately, these currently cause RA to crash:
```
thread '<unnamed>' panicked at 'Fail to convert given literal Literal {
text: "-42.0f32",
id: TokenId(
4294967295,
),
}', crates/mbe/src/subtree_source.rs:161:28
```
This pull request contains both a fix 8cf9362 and a unit test 27798ee. In addition, I installed the patched server with `cargo xtask install --server` and verified in VSCode that it no longer crashes when a procedural macro returns a negative number literal.
Co-authored-by: Tim <tim@glacyr.com>
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932
Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?).
Also renamed the field to better resemble the semantics.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
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>
6127: Correctly complete items with leading underscore r=SomeoneToIgnore a=fmease
Fixes#6091. Let me know if the test is placed into the right file or if it is even desired.
Co-authored-by: León Orell Valerian Liehr <liehr.exchange@gmx.net>
This removes all markdown when the client does not support the markdown MarkupKind
Otherwise the output on the editor will have some markdown boilerplate, making it less readable
This seems like a better factoring logically; ideally, clients shouldn't touch
`set_` methods of the database directly. Additionally, I think this
should remove the unfortunate duplication in fixture code.
5954: Add flexible configuration for runnables r=popzxc a=popzxc
This PR introduces two new configuration options for runnables: `overrideCargo` and `cargoExtraArgs`.
These options are applied to all the "run" tasks of rust analyzer, such as binaries and tests.
Overall motivation is that rust-analyzer provides similar options, for example, for `rustfmt`, but not for runnables.
## `overrideCargo`
This option allows user to replace `cargo` command with something else (well, something that is compatible with the cargo arguments).
Motivation is that some projects may have wrappers around cargo (or even whole alternatives to cargo), which do something related to the project, and only then run `cargo`. With this feature, such users will be able to use lens and run tests directly from the IDE rather than from terminal.
## `cargoExtraArgs`
This option allows user to add any additional arguments for `cargo`, such as `--release`.
It may be useful, for example, if project has big integration tests which take too long in debug mode, or if any other `cargo` flag has to be passed.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6105: Fix path comparison not comparing paths correctly with unequal lengths r=matklad a=Veykril
~~This PR includes the commit from #6102 there as I found a bug while writing that(so either merging this or both in order works) so I included a test there already which was just ignored.~~ This PR fixes that, basically inserting imports didn't consider path length for equality, so depending on the order it might insert the path before or after another import if they only differ in segment length.
~~Diff without the commit of #61022d90d3937d~~
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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>
6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink
This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports).
This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved").
I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6085: Mark unresolved imports diagnostic as experimental r=jonas-schievink a=jonas-schievink
It causes a lot of false positives for people. We collected all of the known ones during the last week.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6073: Dont unnecessarily unnest imports r=matklad a=Veykril
Fixes#6071
This has the side effect that paths that refer to items inside of the current module get prefixed with `self`. Changing this behavior is unfortunately not straightforward should it be unwanted, though I don't see a problem with this as prefixing imports like this with `self` is what I do personally anyways 😅. You can see what I mean with this in one of the tests which had to be changed in `crates/ssr/src/tests.rs`.
There is one test that i still have to look at though, ~~which I by accident pushed with `#[ignore]` on it~~, which is `different_crate_renamed`, for some reason this now doesn't use the crate alias. This also makes me believe that aliases in general will break with this. So maybe this is not as straight forwards as I'd hoped for, but I don't really know how aliases work here.
Edit: The failing test should work now
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6055: Add ok postfix completion r=matklad a=mullr
Wrapping values in `Ok(...)` is so pervasive that it seems reasonable for it to
have its own postfix completion.
Co-authored-by: Russell Mull <russell.mull@gmail.com>
5846: Add references to fn args during completion r=matklad a=adamrk
When completing a function call, if there is an argument taken as a ref or mut ref which matches the name and type of a variable in scope, we will insert a `&` or `&mut` when filling in the function arguments. This addresses https://github.com/rust-analyzer/rust-analyzer/issues/5449.
E.g.
```rust
fn foo(x: &i32) {}
fn main() {
let x = 5;
foo # completing foo here generates `foo(&x)` now instead of `foo(x)`
}
```
Co-authored-by: adamrk <ark.email@gmail.com>
