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>
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>
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>
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>
6365: Do insertion lookahead in algo::diff r=matklad a=Veykril
This is the last blocker for #6287 after this I can update that PR to properly fix things through using `SyntaxRewriter`.
This PR also shuffles tests around a bit and adds some more.
Ideally this is just a hack until we implement a "proper" diff algorithm that approximates a minimal diff. Maybe something like [gumtree](https://github.com/GumTreeDiff/gumtree)?
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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>
6387: do not use associated types placeholder for inlay hint r=flodiebold a=bnjjj
close#6191
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6384: add doctest runnables on struct r=lnicola a=bnjjj
I will check for how to do the same on trait implementation on another PR.
#6356
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6331: correct hover text for items with doc attribute with raw strings r=matklad a=JoshMcguigan
Fixes#6300 by improving the handling of raw string literals in attribute style doc comments.
This still has a bug where it could consume too many `"` at the start or end of the comment text, just as the original code had. Not sure if we want to fix that as part of this PR or not? If so, I think I'd prefer to add a unit test for either the `as_simple_key_value` function (I'm not exactly sure where this would belong / how to set this up) or create a `fn(&SmolStr) -> &SmolStr` to unit test by factoring out the `trim` operations from `as_simple_key_value`. Thoughts on this?
6342: Shorter dependency chain r=matklad a=popzxc
Continuing implementing suggestions from the `Completion refactoring` zulip thread.
This PR does the following:
- Removes dependency of `completions` on `assists` by moving required functionality into `ide_db`.
- Moves completely `call_info` crate into `ide_db` as it looks like it fits perfect there.
- Adds a bunch of new tests and docs.
- Adds the re-export of `base_db` to the `ide_db` and removes direct dependency on `base_db` from other crates.
The last point is controversial, I guess, but I noticed that in places where `ide_db` is used, `base_db` is also *always* used. Thus I think the dependency on the `base_db` is implied by the fact of `ide_db` interfaces, and thus it makes sense to just provide `base_db` out of the box.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6251: Semantic Highlight: Add Callable modifier for variables r=matklad a=GrayJack
This PR added the `HighlightModifier::Callable` variant and assigned it to variables and parameters that are fn pointers, closures and implements FnOnce trait.
This allows to colorize these variables/parameters when used in call expression.
6310: Rewrite algo::diff to support insertion and deletion r=matklad a=Veykril
This in turn also makes `algo::diff` generate finer diffs(maybe even minimal diffs?) as insertions and deletions aren't always represented as as replacements of parent nodes now.
Required for #6287 to go on.
Co-authored-by: GrayJack <gr41.j4ck@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6324: Improve #[cfg] diagnostics r=jonas-schievink a=jonas-schievink
Unfortunately I ran into https://github.com/rust-analyzer/rust-analyzer/issues/4058 while testing this on https://github.com/nrf-rs/nrf-hal/, so I didn't see much of it in action yet, but it does seem to work.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6326: hide paramater inlay hints for cloned vars if applicable r=SomeoneToIgnore a=Veykril
This causes `foo.clone()` parameters to be handled as if they were just `foo` parameters for inlay hint logic.
Fixes#6315
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6299: Diagnose items that are #[cfg]d out r=jonas-schievink a=jonas-schievink
This emits a hint-level diagnostic with `Unnecessary` tag to "gray out" any items whose `#[cfg]` attributes remove the item before name resolution.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Declaration names sounds like a name of declaration -- something you
can use for analysis. It empathically isn't, and is just a label
displayed in various UI. It's important not to confuse the two, least
we accidentally mix semantics with UI (I believe, there's already a
case of this in the FamousDefs at least).
6234: Fix hover over field pattern shorthand r=matklad a=Vlad-Shcherbina
Instead of the information about the field, it now shows the information
about the local.
Fixes#6146
Co-authored-by: Vlad Shcherbina <vlad.shcherbina@gmail.com>
6231: Factor macro_rules and format-string highlighting out into submodules r=Veykril a=Veykril
This moves `format`-like macro string highlighting and macro_rules highlight skipping out of the main module.
Co-authored-by: Lukas Wirth <lukastw97@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.
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.
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>
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>
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.
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>
5976: Complete trait impl immediately after type/const/fn r=jonas-schievink a=oxalica
Currently, we can complete type/const/fn but only if we typed an identifier.
That is, `impl .. { fn f<|> }` has completions with all trait fn including `f`, but `impl .. { fn <|> }` doesn't provide any suggestion (even if explicit trigger it).
This PR tweak the logic of completion match to make it possible.
However, we still need to explicit trigger suggestions (`Control + Space` by default) in vscode to show. Not sure if we can make it automatically triggered after typing the space after `fn`.
Another question is that I cannot figure out why `BLOCK_EXPR` need to be checked. A block expr directly inside a impl block should be invalid, and nested items will failed to locate impl block in specific offset and skip the suggestion. Now I simply removed it and no tests are broken.
4f91478e50/crates/ide/src/completion/complete_trait_impl.rs (L109)
Co-authored-by: oxalica <oxalicc@pm.me>
5985: Make MergeBehaviour configurable r=jonas-schievink a=Veykril
This should make the newly implemented `MergeBehaviour` for import insertion configurable as roughly outlined in https://github.com/rust-analyzer/rust-analyzer/pull/5935#issuecomment-685834257. For the config name and the like I just picked what came to mind so that might be up for bikeshedding.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5971: Implement async blocks r=flodiebold a=oxalica
Fix#4018
@flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail:
- Chalk doesn't support generator type yet.
- Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 )
- The output type of async block should be known after type inference of the whole body.
- We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`.
- During the inference, the output type of async block can be temporary unknown and participate the later inference.
`let a = async { None }; let _: i32 = a.await.unwrap();`
So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type.
And it really works now.
Well, I still have some questions:
- The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here.
- Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type.
Co-authored-by: oxalica <oxalicc@pm.me>
`hir` should know nothing about URLs, markdown and html. It should
only be able to:
* resolve stringy path from documentation
* generate canonical stringy path for a def
In contrast, link rewriting should not care about semantics of paths
and names resolution, and should be concern only with text mangling
bits.
