10747: fix: Remove faulty logic for ascending test attributes for runnables r=Veykril a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10744
- This logic is currently not required as we do not expand test/bench anymore for the time being
- The implementation of this was flawed to begin with as it just skipped out of macro expansions instead of ascending the trees inside expansions
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10745: internal: Replace some more ide usages of ModuleDef with Definition r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10743: feat: index fewer crates on startup/reload r=jonas-schievink a=jonas-schievink
Before this PR, we used to index every crate in the `CrateGraph`, which includes every test, benchmark and example of all packages everywhere. The point of indexing is to speed up future queries, so indexing lots of tiny crates users are unlikely to open isn't really helpful.
This PR instead makes us index only the transitive dependencies of all workspace crates.
This reduces the number of crates we index in the rust-analyzer repo from 617 to 177 (!). Time is not impacted by that much, because most of the skipped crates are tiny.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
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>
10722: fix: Fix proc-macro attributes being shadowed by their functions in IDE layer r=Veykril a=Veykril
We sometimes still didn't resolve proc-macro attrs in attribute paths in the ide crates due to their function definitions resolving first.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10688: internal: Type-check TS on CI and also turn off the strict setting `useUnknownInCatchVariables` r=lnicola a=ChayimFriedman2
We don't follow it and I found that turning it on will have little benefit.
I'm not sure if we should also type-check when building in launch.json.
Co-authored-by: Chayim Refael Friedman <chayimfr@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>
