9846: feat: Generate default trait fn impl when generating `Clone` r=Veykril a=yoshuawuyts
Implements a default trait function body when generating the `Clone` trait for a type. Thanks!
r? `@\veykril`
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9830: Enable more assists to generate default trait body impls r=Veykril a=yoshuawuyts
Enable more assists to benefit from trait body generation. Follow-up to #9825 and #9814.
__edit:__ I'd like to move the existing tests to this new file too, but I'll do that in a follow-up PR.
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9804: Generate method from call r=matklad a=mahdi-frms
Needs a bit of refactoring. Tests also should be added.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
9825: Generate default impl when converting #[derive(Default)] to manual impl r=Veykril a=yoshuawuyts
Similar to https://github.com/rust-analyzer/rust-analyzer/pull/9814, but for `#[derive(Default)]`. Thanks!
## Follow-up steps
I've added the tests inside `handlers/replace_derive_with_manual_impl.rs` again, but I'm planning a follow-up PR to extract these to `utils/` so we can share them between assists - and maybe even add another assist just for the purpose of testing these impls (e.g. `generate_default_trait_body`).
The step after _that_ is likely to fill out the remaining traits, so we can make it so whenever RA auto-completes a trait which also can be derived, we provide a default function body.
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
From the dawn of time, when dinosaurs roamed the and we didn't have
hierarchical profiling, there was the `latest_requests` infra we used to
track the time of ten last requests.
Today, no one is actually using it and, what's more, it itself became
pretty useless -- LSP grew way more chatty, and 10 requests don't really
paint any kind of picture.
Personally, it's been years since I last looked at latest requests in
the status output.
So, let's remove a tiny bit of state from the big ball of complexity
that is `GlobalState` and `main_loop`!
Today, rust-analyzer (and rustc, and bat, and IntelliJ) fail badly on
some kinds of maliciously constructed code, like a deep sequence of
nested parenthesis.
"Who writes 100k nested parenthesis" you'd ask?
Well, in a language with macros, a run-away macro expansion might do
that (see the added tests)! Such expansion can be broad, rather than
deep, so it bypasses recursion check at the macro-expansion layer, but
triggers deep recursion in parser.
In the ideal world, the parser would just handle deeply nested structs
gracefully. We'll get there some day, but at the moment, let's try to be
simple, and just avoid expanding macros with unbalanced parenthesis in
the first place.
closes#9358
We generally avoid "syntax only" helper wrappers, which don't do much:
they make code easier to write, but harder to read. They also make
investigations harder, as "find_usages" needs to be invoked both for the
wrapped and unwrapped APIs
9814: Generate default impl when converting `#[derive(Debug)]` to manual impl r=yoshuawuyts a=yoshuawuyts
This patch makes it so when you convert `#[derive(Debug)]` to a manual impl, a default body is provided that's equivalent to the original output of `#[derive(Debug)]`. This should make it drastically easier to write custom `Debug` impls, especially when all you want to do is quickly omit a single field which is `!Debug`.
This is implemented for enums, record structs, tuple structs, empty structs - and it sets us up to implement variations on this in the future for other traits (like `PartialEq` and `Hash`).
Thanks!
## Codegen diff
This is the difference in codegen for record structs with this patch:
```diff
struct Foo {
bar: String,
}
impl fmt::Debug for Foo {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
- todo!();
+ f.debug_struct("Foo").field("bar", &self.bar).finish()
}
}
```
Co-authored-by: Irina Shestak <shestak.irina@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
9808: fix: Look for enum variants and trait assoc functions when looking for lang items r=matklad a=Veykril
Examples for lang enum variants are the `Option` variants.
Assoc trait functions aren't being seen since they aren't declared in the direct module scope.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9785: feature: Add completion for struct literals in which all fields are visible. r=Veykril a=Afourcat
This PR adds a new completion for struct literal.
It Implements the feature discussed in the issue #9610.
This PR introduce a repetition in the source files `crates/ide_completion/render/pattern.rs` and `crates/ide_completion/render/struct_literal.rs` that may be fix in another PR.
Co-authored-by: Alexandre Fourcat <afourcat@gmail.com>
Fix ide_completion tests.
Move 'complete_record_literal' call to the main completion function.
Fix a rendering bug when snippet not available.
Checks if an expression is expected before adding completion for struct literal.
Move 'completion struct literal with private field' test to 'expressions.rs' test file.
Update 'expect' tests with new check in 'complete record literal'.
9734: semantic highlighting: add reference hlmod r=matklad a=jhgg
This PR adds the "reference" highlight modifier!
I basically went around and looked for `HlMod::Mutable` to find the callsites to add a reference. I think these all make sense!
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
9773: internal: Improve `extract_function` assist r=Veykril a=Veykril
- fix: It doesn't try to overwrite parts of selected comments any longer
- fix: It doesn't wrap tail expressions and return types in a result or option unnecessarily
- feat?: It now adds a `const` modifier to the created function if extract somethings from a const context
Fixes#7840
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9764: fix: Don't use the module as the candidate node in fuzzy path flyimport r=Veykril a=Veykril
The problem was that the candidate node is whats being used for the scope, so using an inline module will yield the surrounding scope of the module instead of the scope of the module itself.
Also seems to fix the problem in this comment https://github.com/rust-analyzer/rust-analyzer/issues/9760#issuecomment-891125674, though I could not recreate that in a test for some reason.
Fixes#9760
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9751: Make `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` public again r=matklad a=regexident
This [commit](b24f816c0d) which restricted the visibility of `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` unfortunately effectively rendered every crate/tool that uses rust-analyzer as a library dead in the water.
On of such tools is [cargo-modules](https://github.com/regexident/cargo-modules), a tool for generating tree/graph visualizations of one's Rust project and is powered by rust-analyzer as a library.
For more context see the PRs that introduced those types/functions and made them `pub`:
- https://github.com/rust-analyzer/rust-analyzer/pull/7595
- https://github.com/rust-analyzer/rust-analyzer/pull/7690
If kept as is rust-analyzer would effectively no longer be usable as a library.
cc `@SomeoneToIgnore`
Co-authored-by: Vincent Esche <regexident@gmail.com>
9752: feature: Declare proc-macro dependent crates in `rust-project.json` r=matklad a=tobywf
This adds the `is_proc_macro` flag in `rust-project.json`. By default, this is `false` and not required, so existing projects won't break/have the same behavior as before this change. If the flag is true, a dependency to the `proc_macro` sysroot crate is added (if it exists), so that rust-analyzer can resolve those imports.
This fixes#9726 .
I've also added some tests in the second commit. The first is a smoke test for a basic, minimal `rust-project.json` file. The second is a more targeted test for the flag. Both tests depend on the fake sysroot (a bunch of directories in the correct layout with empty `lib.rs` files), and also on `env!("CARGO_MANIFEST_DIR")` being an absolute path. I'm not sure if the later assumption is valid on all platforms. I wanted to at least try and add tests, but I'm happy to rework them or remove them if you don't think that's the way to go.
(You can license/relicense my contribution in any way you wish without contacting me.)
Co-authored-by: Toby Fleming <sourcecode@tobywf.com>
9746: internal: add API to check what are the max limits in practice r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
9739: generate function assist favors deref cmpt types r=matklad a=mahdi-frms
Fixes#9713
Although that's still not relying on sematic info.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.
Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.
That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via `extensions`
field of the ClientCapabilities.
To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.
So, if you maintain a rust-analyzer client and implement
`rust-analyzer/runSingle` and such, please also advertise this via a
capability.
9731: feat: Add `replace_char_with_string` assist r=Veykril a=Veykril
Adds the counterpart for the `replace_string_with_char` assist and fixes the assist not escaping the `'` in the string `"'"` when transforming that to a char.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9700: fix: Remove the legacy macro scoping hack r=matklad a=jonas-schievink
This stops prepending `self::` to single-ident macro paths, resolving even legacy-scoped macros using the fixed-point algorithm. This is not correct, but a lot easier than fixing this properly (which involves pushing a new scope for every macro definition and invocation).
This allows resolution of macros from the prelude, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9687.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9693: feat: Add the Hover Range capability which enables showing the type of an expression r=matklad a=alexfertel
Closes https://github.com/rust-analyzer/rust-analyzer/issues/389
This PR extends the `textDocument/hover` method to allow getting the type of an expression. It looks like this:
Edit: One thing I noticed is that when hovering a selection that includes a macro it doesn't work, so maybe this would need a follow-up issue discussing what problem that may have.
(PS: What a great project! I am learning a lot! 🚀)
Co-authored-by: Alexander Gonzalez <alexfertel97@gmail.com>
Co-authored-by: Alexander González <alexfertel97@gmail.com>
9558: Do not erase Cargo diagnostics from the closed documents r=matklad a=SomeoneToIgnore
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6850
The LSP specification at https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textDocument_publishDiagnostics states that
> Diagnostics notification are sent from the server to the client to signal results of validation runs.
>
> Diagnostics are “owned” by the server so it is the server’s responsibility to clear them if necessary. The following rule is used for VS Code servers that generate diagnostics:
>
> * if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed.
> * if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).
>
> When a file changes it is the server’s responsibility to re-compute diagnostics and push them to the client. If the computed set is empty it has to push the empty array to clear former diagnostics. Newly pushed diagnostics always replace previously pushed diagnostics. There is no merging that happens on the client side.
So for projects we should not clear any diagnostics from cargo/json projects.
Our "standalone file" mode is in a way a project too, with sysroot attached and a potential support for dynamic standalone files.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
9593: fix: Adding remove_unused_param for method and fixing same for assoc func r=matklad a=feniljain
Solves #9571
Co-authored-by: vi_mi <fenil.jain2018@vitstudent.ac.in>
9681: Respect `#[doc(hidden)]` in dot-completion r=jonas-schievink a=jonas-schievink
This adds `CompletionContext::is_visible` as a convenience method that checks visibility, presence of `doc(hidden)`, and whether the completed item is in the same crate as the completion site or not. We only complete `doc(hidden)` items from the same crate.
This doesn't yet work for *all* completions: `qualified_path` completions use `Module::scope` and `ScopeDef`, which doesn't work with this.
Part of https://github.com/rust-analyzer/rust-analyzer/issues/7718
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9674: fix: Fix pattern name resolution when name is also occupied in type namespace r=flodiebold a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8694
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9634: minor update to excludeDirs doc r=lnicola a=dae
I saw reference to globs in #7755, but it doesn't look like they're
actually supported, and I had to dig through the source to discover
that the folders are relative to the workspace root. Further digging
was required to get VS Code from hanging for long periods trying to
watch giant Bazel folders that had already been excluded from Rust
Analyzer. Hopefully this tweak will save others the confusion :-)
Co-authored-by: Damien Elmes <gpg@ankiweb.net>
Co-authored-by: Damien Elmes <dae@users.noreply.github.com>
9453: Add first-class limits. r=matklad,lnicola a=rbartlensky
Partially fixes#9286.
This introduces a new `Limits` structure which is passed as an input
to `SourceDatabase`. This makes limits accessible almost everywhere in
the code, since most places have a database in scope.
One downside of this approach is that whenever you query limits, you
essentially do an `Arc::clone` which is less than ideal.
Let me know if I missed anything, or would like me to take a different approach!
Co-authored-by: Robert Bartlensky <bartlensky.robert@gmail.com>
9652: Don't concat path in replace_qualified assist when they start with a keyword r=Veykril a=Veykril
Also keep the path if we can't find a path to the item instead of becoming non applicable.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9637: Overhaul doc_links testing infra r=Veykril a=Veykril
and fix several issues with current implementation.
Fixes#9617
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9646: add 'use' prefix for any auto-import r=Veykril a=mahdi-frms
Fixes#9643
looks like there was an if condition that had to be removed.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.
So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.
Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.
Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.
Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.
Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
