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?
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 :-)
9614: Parse input expressions for dbg! invocations in remove_dbg r=Veykril a=Veykril
Instead of inspecting the input tokentree manually, parse the input as `,` delimited expressions instead and act on that. This simplifies the assist quite a bit.
Fixes#8455
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9600: fix: Single-line and nested blocks in the `unwrap_block` assist r=Veykril a=patrick-gu
Fixes#8411
Rework the system for stripping whitespace and braces in the unwrap_block assist to allow correct unwrapping of blocks such as:
```rust
{ $0 0 }
```
into
```rust
0
```
and nested blocks, such as:
```rust
$0{
{
3
}
}
```
into
```rust
{
3
}
```
This is done by creating the `update_expr_string_with_pat` function (along with `update_expr_string` and `update_expr_string_without_newline`), which strips whitespace and braces in a way that ensures that only whitespace and a maximum of one brace are removed from the start and end of the expression string.
I have also created several tests to ensure that this functionality works correctly.
Co-authored-by: patrick-gu <55641350+patrick-gu@users.noreply.github.com>
9550: Proc macro multi abi proof of concept r=matklad a=alexjg
#8925 was irritating me so I thought I would have a bash at fixing it. What I've done here is copy the `crates/proc_macro_srv/src/proc_macro` code (which is copied from `<RUST>/library/proc_macro`) to `crates/proc_macro_srv/src/proc_macro_nightly` and the modified the nightly version to include the changes from https://github.com/rust-analyzer/rust-analyzer/pull/9047 and aeb7b183a2
This gives us the code to support both stable and nightly ABIs. Then we use the `proc_macro_api::version::read_dylib_info` to determine which version of the ABI to load when creating a `ProcMacroLibraryLibLoading` (which is now an enum).
This seems to work for me. The code could be cleaned up but I wanted to see if the approach makes sense before I spend more time on it.
I've split the change into two commits, the first is just copying and modifying the `proc_macro` crate, the second contains most of the interesting work around figuring out which ABI to use.
Co-authored-by: Alex Good <alex@memoryandthought.me>
Co-authored-by: alexjg <alex@memoryandthought.me>
In rust-analyzer, we avoid defualt impls for types which don't have
sensible, "empty" defaults. In particular, we avoid using invalid
indices for defaults and similar hacks.
Rather than a "Stable" and "Nightly" ABI we instead name ABIs based on
the version of the rust compiler in which they were introduced. We place
these ABIs in a new module - `proc_macro_srv::abis` - where we also add
some mchinery to abstract over ABIs. This should make it easy to add new
ABIs at a later date as the rust compiler evolves.
9535: internal: remove proc macro management thread r=jonas-schievink a=jonas-schievink
Communication with the proc macro server process has always happened one request at a time, so the additional thread isn't really needed (it just forwarded each request, and sent back the response). This removes some indirection that was a bit hard to understand (a channel was allocated and sent over another channel to return the response).
Hope I'm not missing anything here
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9569: internal: Explicitly check for reference locals or fields in Name classification r=Veykril a=Veykril
Closes#7524
Inlines all the calls to reference related name classification as well as emits both goto definition targets for field shorthands.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
This treats the consts generated by older synstructure versions like
unnamed consts. We should remove this at some point (at least after
Chalk has switched).
9567: remove unneded special case r=matklad a=matklad
bors r+
🤖
9568: feat: add 'for' postfix completion r=lnicola a=mahdi-frms
adds #9561
used ```ele``` as identifier for each element in the iteration
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
9553: minor: Disambiguate replace with if let assist labels r=Veykril a=Veykril
Turns out we have two assists for replacing something with `if let` constructs, so having the cursor on a `let` keyword inside a match gave you two identical assist labels which is rather confusing.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9555: feat: Enable `auto_import` on ident patterns r=Veykril a=Veykril
Helpful for when you want to import a type in a pattern right before destructuring it.
9556: Bump deps r=lnicola a=lnicola
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
9548: add: Adding self keyword completion in complete_fn_param r=lnicola a=feniljain
Solves #9522
I haven't added Arc<self> for now as there were some conflicting opinions on it
Co-authored-by: vi_mi <fenil.jain2018@vitstudent.ac.in>
... instead of using `AliasTy`. Chalk turns the alias type into the
placeholder during unification anyway, which confuses our method
resolution logic.
Fixes#9530.
9519: Explicitly name all spawned threads r=weirdsmiley a=weirdsmiley
Fixes: [#9385](https://github.com/rust-analyzer/rust-analyzer/issues/9385)
The thread name is shown in debugger as well as panic messages and this
patch makes it easier to follow a thread instead of looking through
full backtrace, by naming all spawned threads according to their
functioning.
Co-authored-by: Manas <manas18244@iiitd.ac.in>
The thread name is shown in debugger as well as panic messages and this
patch makes it easier to follow a thread instead of looking through
full backtrace, by naming all spawned threads according to their
functioning.
9500: internal: Only inline closure, literal and local arguments when used once r=Veykril a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/pull/9474#discussion_r663881507 for reasoning.
This still inlines single use closures and literals as naming these is usually not as useful. Prime examples being the Option/Result consuming functions like `map_or` etc.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9497: Wrap inlined closures in parens when inlined in an expression in `inline_call` r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Note that, while we don't currently have a fuzzy-matching score, it
makes sense to special-case postfix templates -- it's very annoying when
`.not()` gets sorted before `.not`. We might want to move this infra to
fuzzy matching, once we have that!
Before this PR, SourceChange used a bool and CompletionItem used an enum
to signify if edit is a snippet. It makes sense to use the same pattern
in both cases. `bool` feels simpler, as there's only one consumer of
this API, and all producers are encapsulated anyway (we check the
capability at the production site).
One source completion can produce up to two lsp completions.
Additionally, `preselct` and `sort_text` are global properties of the
whole set of completions, so the right granularity here is to convert
many completions.
As a side-benefit, we no loger allocate intermediate vec.
Moving tests to `rust-analyzer` crate allows removing walkdir dependency
from `xtask`. It does seem more reasonable to keep tidy tests outside of
the "build system" and closer to other integration tests.
* Keep codegen adjacent to the relevant crates.
* Remove codgen deps from xtask, speeding-up from-source installation.
This regresses the release process a bit, as it now needs to run the
tests (and, by extension, compile the code).
9455: feat: Handle not let if expressions in replace_if_let_with_match r=Veykril a=Veykril
Transforms bare `if cond {}` into `_ if cond` guard patterns in the match as long as at least one `if let` is in the if chain, otherwise the assist wont be applicable.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9454: feat: Empower `replace_if_let_with_match` r=Veykril a=Veykril
Now instead of only working on `if let ... {} else {}` if expressions it now works on all of them where the condition expression is the same text-wise.
This includes if let expressions without an else block, in which case a simple `_ => ()` will be generated in the resulting match but also in more complex cases where multiple `if let` expressions are chained.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9452: feat: Add "View Crate Graph (Full)" r=jonas-schievink a=jonas-schievink
Works like "View Crate Graph", but also includes crates.io and sysroot dependencies. The resulting graph might be enormous.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8867
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9450: internal: Add ModuleOrItem guess to import granularity guessing r=Veykril a=Veykril
I think this should be the last fix needed for this(🤞)
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9436: minor: Add test for macro expanded test module in runnables r=Veykril a=Veykril
Expected this to fail as thats behaving incorrectly on current nightly but I think I fixed this accidentally with https://github.com/rust-analyzer/rust-analyzer/pull/9435
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9269: Recreate status page r=lnicola a=Milo123459
I'm working on redesigning the status page.
Co-authored-by: Milo <50248166+Milo123459@users.noreply.github.com>
9423: fix: Resolve attribute paths in attribute highlighting r=Veykril a=Veykril
Attributes have a new highlighting format now, whereas the `#[` `]` tokens are now tagged with `attribute.attribute` like before, but all other idents inside token trees are now `generic.attribute`. If a path in an attribute can't be resolved it will instead get the `builtinAttribute.attribute` tags now as highlighting doesn't know about builtins like `allow` yet, so we don't want to emit unresolved references.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9418: internal: Include `self` in usage search for modules in their definition source r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Macro that deep clone the tokens but otherwise preserves source
locations and hygiene info is an interesting case for IDE support. Lets
have this, although we don't actively use it at the moment.
9380: feat: Implement goto_declaration support r=matklad a=Veykril
This is just a simple implementation that falls back to `goto_definition` for everything but modules where it goes to the actual module declaration if possible.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9353: Include extra targets when the pkg_root is not the same as the target root. r=matklad a=rezural
Fixes#7715
For example, if a sub-crate includes sets the path='../somewhere-else/lib.rs', the files will not be in pkg_root , but in the target root's parent.
It may actually be in root.parent().parent(), I'm not sure about that.
At the moment it is just a fix, are there any relevant tests that this could go in? I've got about 1 brain cell left... but im happy to add tests where appropriate.
Co-authored-by: rezural <rezural@protonmail.com>
Definition::visibility was implemented in a rather roundabout way -- by
asking the parent module about the effective visibility.
This is problematic for a couple of reasons:
* first, it doesn't work for local items
* second, asking module about visibility of a child is a linear
operation (that's a problem in itself, tracked in #9378)
Instead, lets ask the declared visibility directly, we have all the code
for it, and need only to actually us it.
9348: output to log file if RA_LOG_FILE is defined in environment r=rezural a=rezural
This adds a check for RA_LOG_FILE, and logs to that if defined. It currently overrides flags.log_file. If this is undesirable, I will add a check.
Co-authored-by: rezural <rezural@protonmail.com>
This story begins in #8384, where we added a smart test for our syntax
highting, which run the algorithm on synthetic files of varying length
in order to guesstimate if the complexity is O(N^2) or O(N)-ish.
The test turned out to be pretty effective, and flagged #9031 as a
change that makes syntax highlighting accidentally quadratic. There was
much rejoicing, for the time being.
Then, lnicola asked an ominous question[1]: "Are we sure that the time
is linear right now?"
Of course it turned out that our sophisticated non-linearity detector
*was* broken, and that our syntax highlighting *was* quadratic.
Investigating that, many brave hearts dug deeper and deeper into the
guts of rust-analyzer, only to get lost in a maze of traits delegating
to traits delegating to macros.
Eventually, matklad managed to peel off all layers of abstraction one by
one, until almost nothing was left. In fact, the issue was discovered in
the very foundation of the rust-analyzer -- in the syntax trees.
Worse, it was not a new problem, but rather a well-know, well-understood
and event (almost) well-fixed (!) performance bug.
The problem lies within `SyntaxNodePtr` type -- a light-weight "address"
of a node in a syntax tree [3]. Such pointers are used by rust-analyzer all
other the place to record relationships between IR nodes and the
original syntax.
Internally, the pointer to a syntax node is represented by node's range.
To "dereference" the pointer, you traverse the syntax tree from the
root, looking for the node with the right range. The inner loop of this
search is finding a node's child whose range contains the specified
range. This inner loop was implemented by naive linear search over all
the children. For wide trees, dereferencing a single `SyntaxNodePtr` was
linear. The problem with wide trees though is that they contain a lot of
nodes! And dereferencing pointers to all the nodes is quadratic in the
size of the file!
The solution to this problem is to speed up the children search --
rather than doing a linear lookup, we can use binary search to locate
the child with the desired interval.
Doing this optimization was one of the motivations (or rather, side
effects) of #6857. That's why `rowan` grew the useful
`child_or_token_at_range` method which does exactly this binary search.
But looks like we've never actually switch to this method? Oups.
Lesson learned: do not leave broken windows in the fundamental infra.
Otherwise, you'll have to repeatedly re-investigate the issue, by
digging from the top of the Everest down to the foundation!
[1]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/.60syntax_highlighting_not_quadratic.60.20failure/near/240811501
[2]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Syntax.20highlighting.20is.20quadratic
[3]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Syntax.20highlighting.20is.20quadratic/near/243412392
The completion of cfg will look at the enabled cfg keys when
performing completion.
It will also look crate features when completing a feature cfg
option. A fixed list of known values for some cfg options are
provided.
For unknown keys it will look at the enabled values for that cfg key,
which means that completion will only show enabled options for those.
9264: feat: Make documentation on hover configurable r=Veykril a=Veykril
This also implements deprecation support for config options as this renames `hoverActions_linksInHover` to `hover_linksInHover`.
Fixes#9232
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9227: Add a config setting to disable the 'test' cfg in specified crates r=matklad a=lf-
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
Core does not need to ever be edited with `#[cfg(test)]` enabled,
as the tests are in another crate.
This PR puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]` for that crate.
Fixes#9203Fixes#9226
Co-authored-by: Jade <software@lfcode.ca>
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
This puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]`.
9334: feat: Allow to disable import insertion on single path glob imports r=Veykril a=Veykril
On by default as I feel like this is something the majority would prefer.
Closes#8490
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9321: Inline generics in const and function trait completions r=Veykril a=RDambrosio016
This PR does a couple of things:
- moves path_transform from ide_assists to ide_db to be shared by both assists and completions
- when completing a const or a function for a trait, it will "inline" any generics in those associated items instead
of leaving the generic's name. For example:
```rust
trait Foo<T> {
const BAR: T;
fn foo() -> T;
}
struct Bar;
impl Foo<u32> for Bar {
// autocompletes to this
fn foo() -> u32;
// and not this (old)
fn foo() -> T;
// also works for associated consts and where clauses
const BAR: u32 = /* */
}
```
Currently this does not work for const generics, because `PathTransform` does not seem to account for them. If this should work on const generics too, `PathTransform` will need to be changed. However, it is uncommon to implement a trait only for a single const value, so this isnt a huge concern.
Co-authored-by: rdambrosio <rdambrosio016@gmail.com>
9258: minor: Give `ImportPrefix` variants better config names r=matklad a=Veykril
I feel like `crate` and `self` work better than `by_crate` and `by_self`. The only reason for the current names were that `Self` doesn't work for the variant name on the rust side so I forgot about setting proper config names on serde layer.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9294: internal: introduce minicore -- a subset of libcore for testing r=matklad a=matklad
Clearly, we need one more fixed point iteration loop!
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
It's better to handle magical cases upper in the stack, because it
allows for better re-use of the general implementation below. So, we
pull the `self` case up here.
The end goal is to put `Definition::rename` to the `ide_db`, because
it's a generally re-usable functionality useful for different ide
features, alongside with the search which is already there.
NavigationTarget is strictly a UI-level thing -- it describes where the
cursor should be placed when the user presses goto definition. It
doesn't make any semantic guaratees about rage and focus range and, as
such, is not suitable for driving renames.
9260: tree-wide: make rustdoc links spiky so they are clickable r=matklad a=lf-
Rustdoc was complaining about these while I was running with --document-private-items and I figure they should be fixed.
Co-authored-by: Jade <software@lfcode.ca>
At the moment, this moves only a single diagnostic, but the idea is
reafactor the rest to use the same pattern. We are going to have a
single file per diagnostic. This file will define diagnostics code,
rendering range and fixes, if any. It'll also have all of the tests.
This is similar to how we deal with assists.
After we refactor all diagnostics to follow this pattern, we'll probably
move them to a new `ide_diagnostics` crate.
Not that we intentionally want to test all diagnostics on this layer,
despite the fact that they are generally emitted in the guts on the
compiler. Diagnostics care to much about the end presentation
details/fixes to be worth-while "unit" testing. So, we'll unit-test only
the primary output of compilation process (types and name res tables),
and will use integrated UI tests for diagnostics.
9244: feat: Make block-local trait impls work r=flodiebold a=flodiebold
As long as either the trait or the implementing type are defined in the same block.
CC #8961
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
9239: fix: Fix coercion in match with expected type r=flodiebold a=flodiebold
Plus add infrastructure to test type mismatches without expect.
CC #8961
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
9204: feat: more accurate memory usage info on glibc Linux r=jonas-schievink a=jonas-schievink
This adds support for the new `mallinfo2` API added in glibc 2.33. It addresses a shortcoming in the `mallinfo` API where it was unable to handle memory usage of more than 2 GB, which we sometimes exceed.
Blocked on https://github.com/rust-lang/libc/pull/2228
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9192: internal: Build test-macros in a build script r=jonas-schievink a=jonas-schievink
This build the test-proc-macros in `proc_macro_test` in a build script, and copies the artifact to `OUT_DIR`. This should make it available throughout all of rust-analyzer at no cost other than depending on `proc_macro_test`, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9067.
This hopefully will let us later write inline tests that utilize proc macros, which makes my life fixing proc macro bugs easier.
Opening this as a sort of RFC, because I'm not totally sure this approach is the best.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9202: feat: Make `MemoryUsage` work on Windows r=jonas-schievink a=jonas-schievink
Unfortunately there is no convenient API for heap statistics, so this instead uses the Commit Charge value, which is the amount of memory that needs to be allocated either in physical RAM or in the page file. This approximation seems to be good enough to find queries that waste a large amount of memory, but it should generally be expected to be off by several MB.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9181: Don't complete values in type position r=jonas-schievink a=Veykril
Will add some proper tests in a bit
9182: fix: don't complete derive macros as fn-like macros r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8518
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9169: internal: steps towards attribute macro token mapping r=jonas-schievink a=jonas-schievink
This doesn't work yet, but we seem to be getting a bit further along (for example, we now stop highlighting `use` items inside item with attribute macros as if they were written verbatim).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9144: Extend convert_tuple_struct_to_named_struct to also apply to enum tuple variants r=matklad a=joshuawarner32
This is largely copied and adapted from the existing `convert_tuple_struct_to_named_struct` code.
Not sure if maybe some of this code can/should be shared between those two assists - but the differences are significant enough to make it at least seem like a non-trivial refactor.
Co-authored-by: Joshua Warner <joshuawarner32@gmail.com>
9164: internal: Reduce the number of direct fields in `CompletionContext` some more r=Veykril a=Veykril
Doesn't make the code much simpler yet.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
e.g. if you have a trait T and `impl T for S` for some struct, if you
goto definition on some function name inside the impl, it will go to the
definition of that function inside the `trait T` block, rather than the
current behaviour of not going anywhere at all.
9148: minor: Prevent renaming of aliases on usages r=Veykril a=Veykril
Otherwise trying to rename a usage that goes through an alias will still rename the aliased item instead, cc https://github.com/rust-analyzer/rust-analyzer/issues/5671
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9130: Prefix/suffix parameter inlay hint hiding heuristic is more strict r=Veykril a=Veykril
Instead of just plainly checking prefix/suffix of the argument string to the parameter name we only check for prefixes and suffixes if they are split apart via an underscore meaning, with the argument `foo`, it will be hidden for the parameter name `foo_bar` but not for `foobar`.
bors r+
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8878
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9127: internal: make variant fields inherit the enum's visibility in the ItemTree r=jonas-schievink a=jonas-schievink
No observable changes from what I can tell, but this is "more correct".
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9119: fix: some minor "extract type alias" fixes r=jonas-schievink a=jonas-schievink
It now correctly works inside traits, and no longer messes up the indentation of the original node
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9117: Allow expand-macro to be invoked anywhere inside a macro call r=Veykril a=Veykril
I don't really see a reason to only limit this to the name-ref of a macro.
bors r+
Closes#4606
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9108: Don't show extract into variable assist for unit expressions r=jonas-schievink a=brandondong
**Reproduction:**
```rust
fn main() {
let mut i = 3;
$0if i >= 0 {
i += 1;
} else {
i -= 1;
}$0
}
```
1. Select the snippet of code between the $0's.
2. The extract into variable assist shows up, pushing down the more useful extract into function assist.
3. The resulting output of selecting the extract into variable assist is valid but with the extracted variable having the unit type:
```rust
fn main() {
let mut i = 3;
let var_name = if i >= 0 {
i += 1;
} else {
i -= 1;
};
var_name
}
```
**Fix:**
- Don't show the extract into variable assist for unit expressions. I could not think of any scenarios where such a variable extraction would be desired.
Co-authored-by: Brandon <brandondong604@hotmail.com>
9112: Fix some bugs in `extract_struct_from_enum_variant` assist r=Veykril a=Veykril
bors r+
Fixes#9100Fixes#9099
Kind of fixes #9109, it now copies all the generics might be incorrect if the variant doesn't use all of them)
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9111: fix: make "extract type alias" place extracted type alias outside of impl r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8717: Update match checking algorithm r=iDawer a=iDawer
I've recently got interest in the match checking to extend the current algo to support reporting witnesses of non-exhaustiveness.
It appears the algo is outdated from rustc's implementation. I decided to rewrite it based on the latest rustc's version. It is a diff-based port to ra codebase. That means you can diff-compare these files to rustc.
I'm striving to keep minimal ra-related changes in the algo to make it easier to backport future changes from the upstream.
Based on upstream algorithm of version rust-lang/rust 1.52.0-nightly (25c15cdbe 2021-04-22)
https://github.com/rust-lang/rust/blob/25c15cdbe/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
The goal of this PR is to cover the current `missing-match-arm` diagnostic.
What is remaining to do:
- [x] Error handling. The errors that are unrelated to match checking will be handled before the check. Just like how it made in rustc.
- [x] Lowering `hir_def::expr::Pat` to `hir_ty::diagnostics::match_check::Pat`. rustc's match checking works on top of `rustc_mir_build::thir::Pat`, which is lowered from `hir::Pat` and carries some extra semantics used by the check. All unrelated checks are done there. RA could use this to rule out running the check on unimplemented cases (`Pat::ConstBlock`, etc).
- [x] ~~Proper~~Loose typecheck of match arm patterns (https://github.com/rust-analyzer/rust-analyzer/pull/8840, https://github.com/rust-analyzer/rust-analyzer/pull/8875).
- [x] Tests from `hir_ty::diagnostics::match_check::tests`.
- [x] Clean up `todo`s
- [x] Test run on real repos https://github.com/rust-analyzer/rust-analyzer/pull/8717#issuecomment-847120265.
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
fn is_useful , more skeletons
Specify a lifetime on pattern references
impl PatStack
fill impl Matrix
PatStack::pop_head_constructor
Index-based approach
struct PatCtxt
fields construction fn Fields::wildcards
split wildcard
fn Constructor::is_covered_by_any(..)
fn Matrix::specialize_constructor(..)
impl Usefulness
Initial work on witness construction
Reorganize files
Replace match checking diagnostic
Handle types of expanded patterns
unit match checking go brrr
8952: add support of impl block for doctest into runnables r=matklad a=bnjjj
close#6356
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9060: feat: Diagnose unimplemented built-in macros r=matklad a=jonas-schievink
A number of built-in attribute macros are unsupported, I thought it might be useful to put a diagnostic on their definition in libcore. Not sure.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9051: Fix incorrect setting descriptions r=lnicola a=sclu1034
Descriptions for diagnostic warning hint and info display were swapped.
Fixes#8485.
Co-authored-by: Lucas Schwiderski <lucas@lschwiderski.de>
9027: feat: Attribute completion is context aware r=Veykril a=Veykril
This splits off the `lint` and `derive` completions into their own submodules of `attribute`.
The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9040: Don't label derive macros with their banged_name r=Veykril a=Veykril
cc https://github.com/rust-analyzer/rust-analyzer/issues/7072#issuecomment-850396203
This doesn't fix it non builtin derives yet I think cause of a FIXME somewhere that doesn't categorize proc-macro derives as derives yet
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9029: minor: test that `ItemTree` makes `hir_def` queries syntax-independent r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8997: internal: stop expanding UseTrees during ItemTree lowering r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8908
Messy diff, but `ItemTree` lowering got simpler, since we now have a strict 1-to-1 mapping between `ast::Item` and `ModItem`.
The most messy part is mapping a single `UseTree` back to its `ast::UseTree` counterpart for diagnostics, but I think the ad-hoc source map built during lowering does the job.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9017: internal: Reduce the number of traits passed through chalk during applicable trait lookup r=SomeoneToIgnore a=SomeoneToIgnore
Inherent traits can be omitted before trait solving, presumably slightly helping https://github.com/rust-analyzer/rust-analyzer/issues/7542 and slightly simplifying the code.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
9015: Merge pattern completion related bools into an enum r=Veykril a=Veykril
The two bools can never both be set so this is basically just a tri-state enum.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9012: feat: add tab stops for keyword completions r=matklad a=eduardocanellas
Add tab stops for all the keywords that I judged fit. I also introduced some line breaks and spaces, following the pattern I saw in the `postfix` module.
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
9002: Move annotations below item attributes r=Veykril a=Veykril
This moves annotations/code lenses below attributes in items, bringing them inline with functions where this is already the case. This is done by changing the annotations covering range to just the name node's range which is also more inline with what the lsp expects which is that the range should ideally only cover a single line.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9000
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8996: Fix bug where library functions were not highlighted as such r=arzg a=arzg
Sorry about forgetting to test this in my last PR.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
8993: fix: don't show pd/ppd completions where it shouldn't be r=flodiebold a=eduardocanellas
Closes #8992
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
8994: Check for subdirs in vfs loader exclusions. r=matklad a=ammkrn
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
Co-authored-by: ammkrn <ammkrn@tuta.io>
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
8990: feat: Also do goto implementation on assoc consts r=lnicola a=lf-
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
Co-authored-by: Jade <software@lfcode.ca>
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
8987: Fix lowering of FnOnce() without return type r=flodiebold a=flodiebold
This should result in an implicit `-> ()`, not leaving out the binding.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
8767: implement range formatting r=matklad a=euclio
Fixes#7580.
This PR implements the `textDocument/rangeFormatting` request using `rustfmt`'s `--file-lines` option.
Still needs some tests. What I want to know is how I should handle the instability of the `--file-lines` option. It's still unstable in rustfmt, so it's only available on nightly, and needs a special flag to enable. Is there a way for `rust-analyzer` to detect if it's using nightly rustfmt, or for users to opt-in?
Co-authored-by: Andy Russell <arussell123@gmail.com>
8986: Add go to type definition for struct fields within struct r=matklad a=lf-
Example:
```rust
struct A;
struct B {
a/*<- cursor*/: A,
}
```
Go to type definition used to not work on this position. It now goes to
`A` as expected.
Co-authored-by: Jade <software@lfcode.ca>
Example:
```rust
struct A;
struct B {
a/*<- cursor*/: A,
}
```
Go to type definition used to not work on this position. It now goes to
`A` as expected.
8942: Add `library` semantic token modifier to items from other crates r=arzg a=arzg
Closes#5772.
A lot of code here is pretty repetitive; please let me know if you have any ideas how to improve it, or whether it’s fine as-is.
Side-note: How can I add tests for this? I don’t see a way for the test Rust code in `test_highlighting` to reference other crates to observe the new behaviour.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
8979: minor: update `CrateGraph` comment r=jonas-schievink a=jonas-schievink
`cfg` flags are now implemented, and crates *may* have names, it doesn't
doesn't matter for name resolution
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8975: Use todo!() as placeholder body for generated match arms r=matklad a=jDomantas
`todo!()` seems to be a better fit for this than `{}`. Seeing that this assist predates stabilization of `todo` my guess is that simply no one bothered to change it yet.
Also fixed the issue where if the last arm was not block-like, rust-analyzer would not add a comma after it and would generate invalid code.
Co-authored-by: Domantas Jadenkus <djadenkus@gmail.com>
8970: fix: duplicate dependencies that have multiple DepKinds r=jonas-schievink a=jonas-schievink
Cargo collapses identical dependencies that are listed under `[dependencies]` and `[build-dependencies]` into a single `NodeDep`. We have to undo that by duplicating the dependency for each of its listed `DepKind`s.
Not doing that would incorrectly treat a dependency as `DepKind::Normal`, even though it is *also* meant to be a `DepKind::Build`.
Fixes https://github.com/rust-analyzer/rust-analyzer/pull/8812#issuecomment-847125395
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8955: feature: Support standalone Rust files r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/6388
Caveats:
* I've decided to support multiple detached files in the code (anticipating the scratch files), but I found no way to open multiple files in VSCode at once: running `code *.rs` makes the plugin to register in the `vscode.workspace.textDocuments` only the first file, while code actually displays all files later.
Apparently what happens is the same as when you have VSCode open at some workplace already and then run `code some_other_file.rs`: it gets opened in the same workspace of the same VSCode with no server to support it.
If there's a way to override it, I'd appreciate the pointer.
* No way to toggle inlay hints, since the setting is updated for the workspace (which does not exist for a single file opened)
> [2021-05-24 00:22:49.100] [exthost] [error] Error: Unable to write to Workspace Settings because no workspace is opened. Please open a workspace first and try again.
* No runners/lens to run or check the code are implemented for this mode.
In theory, we can detect `rustc`, run it on a file and run the resulting binary, but not sure if worth doing it at this stage.
Otherwise imports, hints, completion and other features work.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
8938: internal: Fix#8931 r=flodiebold a=flodiebold
- and add some better checking for similar bugs
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
The problem was the skipping of binders in
`resolve_method_call_as_callable`; this still doesn't use the _correct_
substitution, but at least it doesn't return a type with free variables
in it.
Fixes#8931.
8921: Resolve any lifetime variables to 'static after inference r=flodiebold a=flodiebold
Chalk's unification can sometimes create lifetime variables, which we
currently don't really deal with, but at least we don't want to leak
them outside of inference.
Should fix#8919.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Chalk's unification can sometimes create lifetime variables, which we
currently don't really deal with, but at least we don't want to leak
them outside of inference.
Should fix#8919.
8901: fix: `fill_match_arms` hangs on a tuple of large enums r=matklad a=iDawer
+ Lazy computation of missing arms.
+ Convenience function to test lazy computation: `ide_assists::tests::check_assist_unresolved`.
Fixes#8835
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8856: Use Chalk for unification r=flodiebold a=flodiebold
- use Chalk's unification, get rid of our own `unify`
- rewrite coercion to not use unification internals and to be more analogous to rustc
- fix various coercion bugs
- rewrite handling of obligations, since the old hacky optimization where we noted when an inference variable changes wasn't possible anymore
- stop trying to deeply resolve types all the time during inference, instead only do it shallowly where necessary
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
We can't do the easy hack that we did before anymore, where we kept
track of whether any inference variables changed since the last time we
rechecked obligations. Instead, we store the obligations in
canonicalized form; that way we can easily check the inference variables
to see whether they have changed since the goal was canonicalized.
