10877: feat: make hightlighting linear r=matklad a=matklad
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 :-)
As you can see from then benchmark results, this doesn't actually make analysis stats fastre. I am a bit mystified as to why this is happening to be honest.
Baseline
```
Database loaded: 598.40ms, 304minstr, 118mb (metadata 390.57ms, 21minstr, 841kb; build 111.31ms, 8764kinstr, -214kb)
crates: 39, mods: 824, decls: 18647, fns: 13910
Item Collection: 9.70s, 75ginstr, 377mb
exprs: 382426, ??ty: 387 (0%), ?ty: 285 (0%), !ty: 145
Inference: 43.16s, 342ginstr, 641mb
Total: 52.86s, 417ginstr, 1018mb
```
This PR:
```
Database loaded: 626.34ms, 304minstr, 118mb (metadata 416.26ms, 21minstr, 841kb; build 113.67ms, 8750kinstr, -209kb)
crates: 39, mods: 824, decls: 18647, fns: 13910
Item Collection: 10.16s, 75ginstr, 389mb
exprs: 382426, ??ty: 387 (0%), ?ty: 285 (0%), !ty: 145
Inference: 44.51s, 342ginstr, 644mb
Total: 54.67s, 417ginstr, 1034mb
```
I think we probably should merge the first commit here, but not the second.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
10976: fix: Show case-insensitive exact matches instead of fuzzy flyimport for short paths r=Veykril a=Veykril
And raise the fuzzy trigger from 2 to 3 chars. This way we keep the ability of flyimporting short names like `Rc`.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6917
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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>
10964: minor: Move synstructure hack out of ItemTree lowering r=jonas-schievink a=jonas-schievink
Don't set the name to `None` for the rest of the IDE if it's generated by synstructure.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
10960: fix: fix handling of macros in `extern` blocks r=jonas-schievink a=jonas-schievink
- Removes knowledge of what's in an extern block from `ItemTree`.
- Treats extern blocks as `AssocContainerId` and renames the latter to `ItemContainerId`.
- Threads the container through name resolution (which is a bit messy).
- Considers statics to be associated items, since they can be in an extern block. (it might be better to further distinguish potentially-associated-items from potentially-in-an-extern-block-items, but currently I don't expect much of a benefit)
- Adds a test for the incorrect-case diagnostic demonstrating the impact of this change.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8913
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
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>
10949: Bump parser step limit a little r=lnicola a=lnicola
Fixes#10948
This doesn't actually make the limit configurable, but at least uses the same `Limit` struct, so we can fix all of them at once when we get to it.
We also bump the limit from 10 to 15M, which is a small enough increase to not worry about making the experience worse for non-`windows` users. We still crash when we reach the limit.
bors r+
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
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 :-)
