10978: internal: Only prime direct dependencies of the workspace crates r=jonas-schievink a=lnicola
This reduces the number of primed crates on `self` from 177 to 105.
```text
# baseline
86521 me 20 0 2939M 562M 14320 S 0.0 0.9 0:07.10 37 rust-analyzer
# pr
99947 me 20 0 2935M 549M 14424 S 0.0 0.9 0:07.10 37 rust-analyzer
```
The RAM usage seems to vary a lot, so I'm not sure the improvement shown above is real.
We also drop the topological sorting, although it might still make sense to do the dependencies before the workspace crates. But since it's only used to make the progress reporting a bit more fine, it probably doesn't matter too much.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10958: internal: add "Shuffle Crate Graph" command r=jonas-schievink a=jonas-schievink
May be useful for debugging issues like https://github.com/rust-analyzer/rust-analyzer/issues/10084
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
In https://youtu.be/qvIZZf5dmTE, we've noticed that AstIdMap does a
linear lookup when going from SyntaxNode to Id. This leads to
accidentally quadratic overall performance. Replace linear lookup with a
O(1) hashmap lookup.
Future work: don't duplicate `SyntaxNodePtr` in `AstIdMap` and switch to
"call site dependency injection" style storage (eg, store a
`HashSet<ErasedFileAstId>`).
See the explanation of the work here on YouTube
https://youtu.be/wvEgymUm7cY :-)
10902: Handle multiple cargo check quick fix spans r=Veykril a=brandondong
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/10705.
**Cause:**
- For a cargo check diagnostic with multiple spans, only a single quick fix action would be created at the location of `spans[0]`. Additionally, the hover window details would only show the location of `spans[0]` next to the message.
**Fix:**
- Allow cargo check quick fix actions to be triggerable from multiple selection ranges. Specifically, if the selection intersects with any of the replacement spans, the quick fix action is shown.
- No change in behavior for the hover window details. It's pretty minor and I think showing multiple locations next to the message may be more confusing anyways.
Co-authored-by: Brandon <brandondong604@hotmail.com>
10891: fix: emit trait names in moniker identifier r=Veykril a=tjdevries
Hi,
Not sure if this is the best fix for the problem, but I noticed that functions that part of a trait are not namespaced with the trait name, so this could lead to problems if you had a function and a trait-function both defined in the same module.
Thanks!
TJ
Co-authored-by: TJ DeVries <devries.timothyj@gmail.com>
10872: ide_db: build symbol index from crate def map r=Veykril a=jhgg
fixes#4842, #10764
Is this looking correct? 👀
- [x] build the symbol index based upon the CrateDefMap for the given crate in `crate_symbols`
- [x] make it multi threaded again, and figure out how to cache each moduleid's symbol index in salsa.
- [x] NavigationTarget for names in macros is wrong, need to figure out how to compute a text range in the original file id?
- [x] cleanup some duped code
- [x] collect macros from `ItemScope.declared_macros()` into symbol index.
- [x] store declared macros in `ItemScope` so we can figure out where macros were defined for the index.
- [x] do something about `SymbolIndex::for_files` - ideally it should use the new module symbol index stuff.
- [x] delete `source_file_to_file_symbols` & co...
- [x] figure out what to do about `library_symbols`
- [x] maybe... speed up the new `library_symbols` - the new impl is probably much slower, and definitely much less parallel. **deciding to do nothing here, we can optimize later if necerssary.**
- [x] fix failing test: `navigation_target::tests::test_nav_for_symbol` - notably the crate def map doesn't seem to find declarations inside function.
- [x] now a bunch of other tests are failing around auto_import & qualify_path handlers. :(
- [x] need to assoc items in traits and impls
Co-authored-by: Jake Heinz <jh@discordapp.com>
10824: project_model: print full cargo command if cargo metadata fails to run r=Veykril a=jhgg
well, `Command` implements a sensible `Debug` which *roughly* does what we want to do. Unfortunately it's got a bit of a quote situation,
So it'd output something like `"cargo" "metadata" "--format-version" "1" "--features" "foo,bar,baz"`.
Which although is a bit verbose with the quotes, it's at the very least, not entirely incorrect/misleading.
fixes#10797
Co-authored-by: Jake Heinz <jh@discordapp.com>
10847: fix: derive attr path handling in `replace_derive_with_manual_impl` r=rainy-me a=rainy-me
partially fixes#10666
renaming issues mentioned in https://github.com/rust-analyzer/rust-analyzer/issues/10666#issuecomment-955671021 doesn't seem to be fixable at this moment since it's not searchable?(not recorded?) by name.
<del>I'm not sure if it's appropriate to move `parse_comma_sep_paths` function to a method in `ast/node_ext`, maybe `ide_db::helpers` also make sense.</del> put into `ide_db::` instead.
Co-authored-by: rainy-me <github@yue.coffee>
10846: fix: qualify struct name in struct constructor completion r=Veykril a=andrewleverette
* Alter `add_struct_literal` method signature to take an optional module path
* Update `render_literal` method to use a qualified
Relates to issue #10771
Side note: This is my first contribution. Any feedback is welcome!
Co-authored-by: Andrew Leverette <andrewleverette@gmail.com>
10840: fix: Omit generic defaults for types in hover messages r=jonas-schievink a=Veykril
Fixes#9198
We have ranged hovers now which query specifically for the type of an expression/pattern, so if interested in seeing the default, the user can use that functionality instead.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10834: Make lint groups work correctly with `warningsAsInfo` and `warningsAsHint` r=Veykril a=Emilgardis
this change makes it possible to specify
```json
{
"rust-analyzer.diagnostics.warningsAsInfo": ["unused"],
}
```
to make all lints in the `unused` group show as info, etc.
Co-authored-by: Emil Gardström <emil.gardstrom@gmail.com>
10809: fix: don't discard formatting of `use` lines r=Veykril a=iDawer
Use mutable syntax trees in `merge_imports`, `split_imports`. This tries to resolve#9013. But I haven't much managed to simplify code of merging.
Also resolve#9361. It reuses a use tree under the cursor so that comments+indentation are preserved. Merged trees are just appended to the end.
This touches bunch of tests. I removed the sorting of use trees as it needs a proper implementation that takes into account comments and line wrapping. I think it is rustfmt's job or at least until we get a close implementation.
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.com>
10810: feat: Add toggle to disable cache priming r=jonas-schievink a=lnicola
Even if it doesn't prevent the rest of the features from working, cache priming tends to be quite CPU-intensive and can make people think that the load times are worse than they actually are.
It's also less useful in Code and `rust-tools` because the inlay hints and semantic highlighting trigger quite a bit of computation assuming you have a file open in the editor.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10821: fix: wrap `inline_call` and `inline_into_callers` if it inlines into the left side of a binary expression r=Veykril a=rainy-me
close#10359
Co-authored-by: rainy-me <github@yue.coffee>
10819: internal: Replace some `Vec` occurences with `Box` r=Veykril a=Veykril
Shaves off ~15mb from self analysis
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10798: ide: show go to for function hover return type r=Veykril a=jhgg
I've found myself wanting this... adds to the hover quick go-to for a function's return type:
This is particularly useful when you are hovering over a function in a long chain, like:
```rust
foo.bar().b$0az().some_trait_fn();
```
where `baz`'s return type is not immediately obvious, but the chain is not long enough to trigger chain inlay hints...
i guess I could just select `foo.bar().baz()` too to get the types too...
Co-authored-by: Jake Heinz <jh@discordapp.com>
10796: ide: display static values in hover r=Veykril a=jhgg
Continuation from #10785 - does the same thing, but for `static`'s as well.
Co-authored-by: Jake Heinz <jh@discordapp.com>
10795: Remove unwrap in doc path resolution r=Veykril a=udoprog
I keep hitting this constantly in my project, and I haven't dug very deep into the root cause. But seeing as the project otherwise compiles it appears to be something unsupported is being incorrectly parsed in rust-analyzer which for other cases is handled by returning `None`.
Co-authored-by: John-John Tedro <udoprog@tedro.se>
10785: ide: show const value in hover r=jhgg a=jhgg
fixes#10783
I think my original attempt was incorrect, because it looks like `HirDisplay` is used in more places than just the hover.
So, I've attempted it again in 312eafe, this time specifically just rendering the value in `hover::render`
pictoral:
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
10781: internal: Do not use reference search in `runnables::related_tests` r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10778: internal: Skip test/bench attr expansion in resolution instead of collection r=Veykril a=Veykril
This way we skip any path resolving to the test and bench attributes instead of just the lone identifiers(which could very well point to non-builtin attributes).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10769: Add proc macro ABI for rustc 1.58 r=lnicola a=alexjg
This fixes#10766.
I do have some concerns here. The proc macro server API has added three methods to `TokenStream` which I don't really know how to implement in `RustcServer`. Namely `expand_expr`, `before`, and `after`. You'll see that these are currently `unimplemented!` in `crates/proc_macro_server/src/abis/abi_1_58/rustc_server.rs`. I don't have the expertise to fill in the blanks here, it may be necessary to pull in someone who knows a bit more about the proc macro crate.
I think this will only be a problem when actually attempting to expand a macro, so this is probably strictly better than not including the updated ABI at all.
Co-authored-by: Alex Good <alex@memoryandthought.me>
Revert "Fix `impl_trait` function to emit correct ast"
This reverts commit 55a4813151.
Fix `impl_def_from_trait`
It now generates the correct `ast::Impl` using
`generate_trait_impl_text` and parses it to form the right node (copied
from the private fn 'make::ast_from_text').
Cargo will always output something on success:
```
$ cargo check --message-format=json
{"reason":"compiler-artifact", ... snipped ... }
{"reason":"build-finished","success":true}
```
However, rustc does not output anything on success:
```
$ rustc --error-format=json main.rs
$ echo $?
0
```
Restore the behaviour prior to #10517, where an exit code of 0 is
considered good even if nothing is written to stdout.
This enables custom overrideCommand values that use rustc rather than
cargo.
10689: Handle pub tuple fields in tuple structs r=Veykril a=adamrk
The current implementation will throw a parser error for tuple structs
that contain a pub tuple field. For example,
```rust
struct Foo(pub (u32, u32));
```
is valid Rust, but rust-analyzer will throw a parser error. This is
because the parens after `pub` is treated as a visibility context.
Allowing a tuple type to follow `pub` in the special case when we are
defining fields in a tuple struct can fix the issue.
I guess this is a really minor case because there's not much reason
for having a tuple type within a struct tuple, but it is valid rust syntax...
Co-authored-by: Adam Bratschi-Kaye <ark.email@gmail.com>
The current implementation will throw a parser error for tuple structs
that contain a pub tuple field. For example,
```rust
struct Foo(pub (u32, u32));
```
is valid Rust, but rust-analyzer will throw a parser error. This is
because the parens after `pub` is treated as a visibility context.
Allowing a tuple type to follow `pub` in the special case when we are
defining fields in a tuple struct can fix the issue.
10738: internal: Do not search through all three namespaces in `ItemScope::name_of` r=Veykril a=Veykril
Brings down `5ms - find_path_prefixed (46 calls)` to `1ms - find_path_prefixed (46 calls)` for me on the `integrated_completion_benchmark`.
Still `O(n)` but this should considerably cut down lookups nevertheless(as shown by the timings already).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10699: internal: Make CompletionItem `label` and `lookup` fields `SmolStr`s r=Veykril a=Veykril
This replaces a bunch of String clones with SmolStr clones, though also makes a few parts a bit more expensive(mainly things involving `format!`ted strings as labels).
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10704: internal: Short-circuit `descend_into_macros_single` r=Veykril a=Veykril
There is no need to descend everything if all we are interested in is the first mapping.
This bring `descend_into_macros` timing in highlighting in `rust-analyzer/src/config.rs` from `154ms - descend_into_macros (2190 calls)` to `24ms - descend_into_macros (2190 calls)` since we use the single variant there(will regress once we want to highlight multiple namespaces again though).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10703: internal: Don't check items for macro calls if they have no attributes r=Veykril a=Veykril
Turns out when highlighting we currently populate the Dynmaps of pretty much every item in a file, who would've known that would be so costly...
Shaves off 250 ms for the integrated benchmark on `rust-analyzer/src/config.rs`.
We are still looking at a heft `154ms - descend_into_macros (2190 calls)` but I feel like this is slowly nearing towards just call overhead.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10701: internal: Cache ast::MacroCalls to their expansions in Semantics::descend_into_macros_impl r=Veykril a=Veykril
Saves ~45ms when highlighting `rust-analyzer/src/config.rs` for me
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10686: internal: Add `Semantics::original_ast_node` for upmapping nodes out of macro files r=Veykril a=Veykril
Fixes trying to insert imports into macro expanded files which then do text edits on very wrong text ranges.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10623: internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack r=matklad a=matklad
The general problem we are dealing with here is this:
```
macro_rules! thrice {
($e:expr) => { $e * 3}
}
fn main() {
let x = thrice!(1 + 2);
}
```
we really want this to print 9 rather than 7.
The way rustc solves this is rather ad-hoc. In rustc, token trees are
allowed to include whole AST fragments, so 1+2 is passed through macro
expansion as a single unit. This is a significant violation of token
tree model.
In rust-analyzer, we intended to handle this in a more elegant way,
using token trees with "invisible" delimiters. The idea was is that we
introduce a new kind of parenthesis, "left $"/"right $", and let the
parser intelligently handle this.
The idea was inspired by the relevant comment in the proc_macro crate:
https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None
> An implicit delimiter, that may, for example, appear around tokens
> coming from a “macro variable” $var. It is important to preserve
> operator priorities in cases like $var * 3 where $var is 1 + 2.
> Implicit delimiters might not survive roundtrip of a token stream
> through a string.
Now that we are older and wiser, we conclude that the idea doesn't work.
_First_, the comment in the proc-macro crate is wishful thinking. Rustc
currently completely ignores none delimiters. It solves the (1 + 2) * 3
problem by having magical token trees which can't be duplicated:
* https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic
* https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser
_Second_, it's not like our implementation in rust-analyzer works. We
special-case expressions (as opposed to treating all kinds of $var
captures the same) and we don't know how parser error recovery should
work with these dollar-parenthesis.
So, in this PR we simplify the whole thing away by not pretending that
we are doing something proper and instead just explicitly special-casing
expressions by wrapping them into real `()`.
In the future, to maintain bug-parity with `rustc` what we are going to
do is probably adding an explicit `CAPTURED_EXPR` *token* which we can
explicitly account for in the parser.
If/when rustc starts handling delimiter=none properly, we'll port that
logic as well, in addition to special handling.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
10629: Add assist for replacing turbofish with explicit type. r=Veykril a=terrynsun
Converts `::<_>` to an explicit type assignment.
```
let args = args.collect::<Vec<String>>();
```
->
```
let args: Vec<String> = args.collect();
```
Closes#10285
Co-authored-by: Terry Sun <terrynsun@gmail.com>
10649: internal: Remove `CompletionKind` in favor of `CompletionItemKind` r=Veykril a=Veykril
and move some more tests around
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10642: minor: Add dummy impls for `trace_macros` and `log_syntax` r=Veykril a=Veykril
Both of these are macros for debugging macros and as such don't really need an implementation for us.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2212
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10633: fix: Implement most proc_macro span handling for other ABIs r=Veykril a=Veykril
Follow up to #10378
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10634: minor: Drop resolver and `authors` manifest entry in `limit` r=lnicola a=lnicola
The new resolver is on by default in the 2021 edition,
bors r+
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10631: fix: Fix postfix completions panicking r=Veykril a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10243, I couldn't reproduce the panic with the given snippet, but this change should still guard against it.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Converts `::<_>` to an explicit type assignment.
```
let args = args.collect::<Vec<String>>();
```
->
```
let args: Vec<String> = args.collect();
```
Closes#10285
The general problem we are dealing with here is this:
```
macro_rules! thrice {
($e:expr) => { $e * 3}
}
fn main() {
let x = thrice!(1 + 2);
}
```
we really want this to print 9 rather than 7.
The way rustc solves this is rather ad-hoc. In rustc, token trees are
allowed to include whole AST fragments, so 1+2 is passed through macro
expansion as a single unit. This is a significant violation of token
tree model.
In rust-analyzer, we intended to handle this in a more elegant way,
using token trees with "invisible" delimiters. The idea was is that we
introduce a new kind of parenthesis, "left $"/"right $", and let the
parser intelligently handle this.
The idea was inspired by the relevant comment in the proc_macro crate:
https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None
> An implicit delimiter, that may, for example, appear around tokens
> coming from a “macro variable” $var. It is important to preserve
> operator priorities in cases like $var * 3 where $var is 1 + 2.
> Implicit delimiters might not survive roundtrip of a token stream
> through a string.
Now that we are older and wiser, we conclude that the idea doesn't work.
_First_, the comment in the proc-macro crate is wishful thinking. Rustc
currently completely ignores none delimiters. It solves the (1 + 2) * 3
problem by having magical token trees which can't be duplicated:
* https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic
* https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser
_Second_, it's not like our implementation in rust-analyzer works. We
special-case expressions (as opposed to treating all kinds of $var
captures the same) and we don't know how parser error recovery should
work with these dollar-parenthesis.
So, in this PR we simplify the whole thing away by not pretending that
we are doing something proper and instead just explicitly special-casing
expressions by wrapping them into real `()`.
In the future, to maintain bug-parity with `rustc` what we are going to
do is probably adding an explicit `CAPTURED_EXPR` *token* which we can
explicitly account for in the parser.
If/when rustc starts handling delimiter=none properly, we'll port that
logic as well, in addition to special handling.
10603: fix: Don't resolve attributes to non attribute macros r=Veykril a=Veykril
Also changes `const`s to `static`s for `Limit`s as we have interior mutability in those(though only used with a certain feature flag enabled).
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
