6785: Fix "no value set for FileTextQuery(FileId(..))" r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6622
Let's hope I got it right this time, but I feel like I slowly begin to understand the main loop logic.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6771: Properly attach inner attributes in Attrs::new r=matklad a=Veykril
Properly attach inner and outer attributes to the things they actually belong to in the HIR. ~~I can add some tests for this if wanted once I know where to put them/how to test for this.~~ Put some tests into `hover.rs`.
So the following snippet
```rust
mod foo {
//! Hello
}
```
now shows `Hello` on hover 🎉Fixes#2148
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6761: Make config.rs a single source of truth for configuration. r=matklad a=matklad
Configuration is editor-independent. For this reason, we pick
JSON-schema as the repr of the source of truth. We do specify it using
rust-macros and some quick&dirty hackery though.
The idea for syncing truth with package.json is to just do that
manually, but there's a test to check that they are actually synced.
I'll add something like `rust-analyzer --config-schema` in a follow-up
commit.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Configuration is editor-independent. For this reason, we pick
JSON-schema as the repr of the source of truth. We do specify it using
rust-macros and some quick&dirty hackery though.
The idea for syncing truth with package.json is to just do that
manually, but there's a test to check that they are actually synced.
There's CLI to print config's json schema:
$ rust-analyzer --print-config-schema
We go with a CLI rather than LSP request/response to make it easier to
incorporate the thing into extension's static config. This is roughtly
how we put the thing in package.json.
6750: Remove documentation query, move doc handling to attributes r=matklad a=Veykril
Fixes#3182
Removes the documentation query in favor of `Attrs::docs`. Attrs already handlded doc comments partially but the alloc saving check was wrong so it only worked when other attributes existed as well. Unfortunately the `new` constructor has to do an intermediate allocation now because we need to keep the order of mixed doc attributes and doc comments.
I've also partially adjusted the `hover` module to have its tests check the changes, it still has some `HasSource` trait usage due to the `ShortLabel` trait usage, as that is only implemented on the Ast parts and not the Hir, should this ideally be implemented for the Hir types as well?(would be a follow up PR of course)
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6752: Pass `--target` when loading out dirs from check r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6719: Use items can also have doc comments r=matklad a=Veykril
Prior to this change modules show more docs than they have cause they inherit the docs from documented use items inside of them.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6745: Some more proc macro cleanups r=jonas-schievink a=jonas-schievink
* Remove `ProcMacroClient::dummy` and just use `Option<ProcMacroClient>` instead
* Remember the type of proc macros (later allows us to reject using an incorrect macro type)
* Prepare a few internals for procedural attribute macros
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6743: Don't insert blank lines between doc attributes r=Veykril a=Veykril
Fixes#6742.
Doc attributes should be concatenated via a single linebreak as written in the [rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html).
Also changed the loop to use an iterator to get rid of the `docs.trim_end_matches("\n\n").to_owned()` part using `Itertools::intersperse`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6731: Add replace_match_with_if_let assist r=matklad a=Veykril
Basically the counterpart to `replace_if_let_with_match`, I personally sometimes want to replace matches like
```rust
match foo {
pat => expr,
_ => (),
}
```
into the corresponding
```rust
if let pat = foo {
expr
}
```
which is the main reasoning behind this.
I put this into the same file as `replace_if_let_with_match` because the are complementing each other and I would probably rename the file to something like `replace_if_let_match` but I didn't do that for now because I was unsure whether git would still view this as a rename or not due to the amount of changes in the file so that the diff is still properly visible for now.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6733: Update attributes completion list r=jonas-schievink a=Veykril
Might be nice to have them grouped for readability/maintainability similar to how the [reference](https://doc.rust-lang.org/reference/attributes.html#built-in-attributes-index) does it but that would require the use of a `OnceCell` for sorting the entries back after construction.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6725: Don't respawn proc macro server on crash r=jonas-schievink a=jonas-schievink
Now the thread managing IPC will exit when the server process crashes instead of respawning it.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/6707
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6724: Fix `diagnostics` subcommand, look at all modules r=jonas-schievink a=jonas-schievink
The `diagnostics` subcommand used to only compute diagnostics for `lib.rs` / the root module of all workspace crates. This fixed it and makes it look at every module.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Without arbitrary self types, the self type could never refer to the method type
parameters, so this wasn't a problem; but with arbitrary self types, it can.
This fixes the crash from #6668; but it doesn't make method resolution work for
these methods.
6700: More macro diagnostics improvements r=jonas-schievink a=jonas-schievink
This threads macro expansion errors through `eager.rs` and the `AsMacroCall` trait, improving macro diagnostics emitted during body lowering.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6698: Attach macro expansion errors to the right file r=jonas-schievink a=jonas-schievink
Previously it attached them to the result of the macro expansion (or, if no result was produced, to the file containing the invocation). Always use the file containing the invocation.
This doesn't seem to have any observable difference, but seems better in theory.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6649: Accept more than just the standard rust literal suffixes in *Number::suffix r=matklad a=Veykril
I am not entirely sure whether to keep or remove the `SUFFIXES` but I figured we can always bring them back once they are needed.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6683: Emit macro diagnostics when lowering bodies r=matklad a=jonas-schievink
Changes `Expander::enter_expand` to return an `ExpandResult`, and adds any contained errors to the body diagnostic list.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6680: Fix use merging not using the first path segment r=Veykril a=Veykril
Finally figured out why nested imports don't properly merge in some cases
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6665: Support self in reference search r=matklad a=Veykril
The approach here is simply checking the descendants of the function body for `PathExpr` then checking whether it only contains a single `self` `PathSegment`, this is to prevent us from picking up `self` tokens from local `UseTree`s.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6599: Add attribute highlight modifier to all tokens inside attributes r=matklad a=Veykril
This has the side effect that we also emit `attribute.attribute` highlights now, as in, the tokens that get the attribute semantic type also get the attribute modifier. I personally don't think it's really a problem but maybe it is to some? It's just that it was really simple to implement it this way, which is why I just went this route for now.
Fixes#6536
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6601: add let and letm postfix to turn expressions into variables r=matklad a=bnjjj
Partially resolve#6426
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6666: Support 'go to definition' for self r=jonas-schievink a=Veykril
Also reverts #6660, instead of showing the type it now works like it does for names by returning the declaration we are already on. This for example enables VSCode to show all references(#6665) when executing `go to definition` on the declaration.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6664: Show type of self param on hover r=jonas-schievink a=Veykril
Show the type of `self` when hovering the token in a `SelfParam`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6645: Publish diagnostics for macro expansion errors r=matklad a=jonas-schievink
This adds 2 new diagnostics, emitted during name resolution:
* `unresolved-proc-macro`, a weak warning that is emitted when a proc macro is supposed to be expanded, but was not provided by the build system. This usually means that proc macro support is turned off, but may also indicate setup issues when using rust-project.json. Being a weak warning, this should help set expectations when users see it, while not being too obstructive. We do not yet emit this for attribute macros though, just custom derives and `!` macros.
* `macro-error`, which is emitted when any macro (procedural or `macro_rules!`) fails to expand due to some error. This is an error-level diagnostic, but currently still marked as experimental, because there might be spurious errors and this hasn't been tested too well.
This does not yet emit diagnostics when expansion in item bodies fails, just for module-level macros.
Known bug: The "proc macro not found" diagnostic points at the whole item for custom derives, it should just point at the macro's name in the `#[derive]` list, but I haven't found an easy way to do that.
Screenshots:
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6650: Make completion and assists module independent r=matklad a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/6553#discussion_r524402907
Move the common code for both assists and completion modules into a separate crate.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6586: Don't call a closure a function in the infer_function_return_type assist label r=lnicola a=Veykril
`Add this function's return type` becomes `Add this closure's return type` for closures. This makes it more obvious that we are indeed planning on modifying the closure and not its containing function.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6618: Properly infer tuple patterns when encountering ellipsis r=Veykril a=Veykril
We basically just split the subpatterns into two halves when the ellipsis is present and then offset the latter half to account for the ignored bindings.
Fixes#6616
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6610: add 'Re-enable this test' assist r=SomeoneToIgnore a=jakobhellermann
The `Ignore this test` assist previously allowed ignoring multiple times, each time adding a `#[ignore]` attribute.
This PR instead shows an assist to undo the ignoring.
Co-authored-by: Jakob Hellermann <jakob.hellermann@protonmail.com>
6553: Auto imports in completion r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/1062 but does not handle the completion order, since it's a separate task for https://github.com/rust-analyzer/rust-analyzer/issues/4922 , https://github.com/rust-analyzer/rust-analyzer/issues/4922 and maybe something else.
2 quirks in the current implementation:
* traits are not auto imported during method completion
If I understand the current situation right, we cannot search for traits by a **part** of a method name, we need a full name with correct case to get a trait for it.
* VSCode (?) autocompletion is not as rigid as in Intellij Rust as you can notice on the animation.
Intellij is able to refresh the completions on every new symbol added, yet VS Code does not query the completions on every symbol for me.
With a few debug prints placed in RA, I've observed the following behaviour: after the first set of completion suggestions is received, next symbol input does not trigger a server request, if the completions contain this symbol.
When more symbols added, the existing completion suggestions are filtered out until none are left and only then, on the next symbol it queries for completions.
It seems like the only alternative to get an updated set of results is to manually retrigger it with Esc and Ctrl + Space.
Despite the eerie latter bullet, the completion seems to work pretty fine and fast nontheless, but if you have any ideas on how to make it more smooth, I'll gladly try it out.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6544: add suggestion ..Default::default() for remaining struct fields in a constructor r=bnjjj a=bnjjj
I'm not sure I should import `assists` crate inside `completions`, maybe we should move out `FamousDefs` from `assists` ? Let me know :)
close#6492
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6524: Add support for loading rustc private crates r=matklad a=xldenis
This PR presents a solution to the problem of making`rustc_private` crates visible to `rust-analyzer`.
Currently developers add dependencies to those crates behind a `cfg(NOT_A_TARGET)` target to prevent `cargo` from building them.
This solution is unsatisfactory since it requires modifying `Cargo.toml` and causes problems for collaboration or CI.
The proposed solution suggested by @matklad is to allow users to give RA a path where the `rustc` sources could be found and then load that like a normal workspace.
This PR implements this solution by adding a `rustcSource` configuration item and adding the cargo metadata to the crate graph if it is provided.
------
I have no idea how this should be tested, or if this code is generally tested at all. I've locally run the extension with these changes and it correctly loads the relevant crates on a `rustc_private` project of mine.
Co-authored-by: Xavier Denis <xldenis@gmail.com>
6514: Fix extract_struct_from_enum_variant not updating record references r=Veykril a=Veykril
Related to #6510
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6513: Support qualified function calls in remove_unused_param r=Veykril a=Veykril
Also adds a test to check that it removes unused params across files.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6472: Add `static` modifier for associated functions r=matklad a=p3achyjr
Adds static semantic token modifier to associated functions, resolves#6194
## Info
- Associated functions are more-or-less equivalent to static methods in other languages. This PR checks, for each function, whether that function has a self_param, and whether it's enclosed in a trait/impl.
## Changes
- Added method ```is_associated``` to code_model::Function. This basically gets the source from the ast, and checks whether the enclosing scope is an impl or trait.
- Added `static` to HighlightModifiers
- Added unit test
## Tests
- Ran ```cargo test```
Co-authored-by: Anatol Liu <axlui@anatols-mbp.lan>
6501: Remove text_edit_builder api from AssistBuilder r=matklad a=Veykril
Also fixes a small bug in `expand_glob_import` in regards to the very nice looking `something::{*}` import when only one item was used. Before it would duplicate the path and just append it, causing the following wrong import `something::something::UsedItem`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6477: Add infer_function_return_type assist r=matklad a=Veykril
This adds an assist to insert a functions return type if it hasn't been specified yet by inferring it from the functions tail expression. This assist only becomes active if the cursor is on the tail expression. See https://github.com/rust-analyzer/rust-analyzer/issues/6303#issuecomment-714657326
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Folks report a ton of hard-to-diagnose issues, the solution for which
is "unset RUST_SRC_PATH". Let's just ignore RUST_SRC_PATH when it
won't work anyway!
6456: Support record variants in extract_struct_from_enum_variant r=matklad a=Veykril
As requested :)
This also prevents the assist from being disabled if a definition in the value namespace exists with the same name as our new struct since that won't cause a collision
#4468
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6458: Qualify trait impl created by add_custom_impl assist r=matklad a=Veykril
When we find at least one trait with the same name as the derive accessible from the current module we now generate a qualified path to that trait in the generated impl.
If we don't find any we just do what was done before and emit the trait name in the generated impl.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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
6287: Don't replace entire module and file nodes when inserting imports r=matklad a=Veykril
This change minifies the resulting diff of import insertions by inserting or replacing the produced use tree directly through an `action` return value instead replacing the entire container node. This action has to be applied by the caller now. This unfortunately pulls the `AssistBuilder` into scope of `insert_use` back again but I tried to at least keep it away from the `insert_use` fn itself.
I'm open to more/better ideas regarding this :)
Fixes#6196
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6401: Only show `self` ident when showing parameter self hints r=matklad a=Veykril
This just hints all self parameters with the `self` token, this is therefor equal to how all other parameters are displayed, but given the self param special in how its defined in a function signature it might make sense to keep the `&`/`&mut` parts as well as emitting those tokens for explict `Self` types that are taken by ref like `self: &Rc<Self>`?
Fixes#6400
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
