bors[bot] [Mon, 13 Dec 2021 18:49:06 +0000 (18:49 +0000)]
Merge #10998
10998: Add number representation assists r=Veykril a=errx
Reimplemented assists from this PR https://github.com/rust-analyzer/rust-analyzer/pull/3683 with current APIs.
![image](https://user-images.githubusercontent.com/462486/145726792-47700215-26f2-4fdc-9520-63d1487901e5.png)
![image](https://user-images.githubusercontent.com/462486/145726802-f528a2f7-9159-41d3-b459-fc3fae033e60.png)
I've decided not to add options about size of the groups so behaviour is similar to clippy's.
Minimal number length is also taken from clippy.
bors[bot] [Mon, 13 Dec 2021 15:43:12 +0000 (15:43 +0000)]
Merge #11000
11000: fix: insert whitespaces into assoc items for assist when macro generated r=Veykril a=Veykril
This is obviously only a temporary hack which still produces ugly looking items, but as long as the syntax is valid one can at least have rustfmt fix the formatting again.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6588
bors r+
bors[bot] [Sun, 12 Dec 2021 16:38:56 +0000 (16:38 +0000)]
Merge #10995
10995: internal: switch from trait-based TokenSource to simple struct of arrays r=matklad a=matklad
cc #10765
The idea here is to try to simplify the interface as best as we can. The original trait-based approach is a bit over-engineered and hard to debug. Here, we replace callback with just data. The next PR in series will replace the output `TreeSink` trait with data as well.
The biggest drawback here is that we now require to materialize all parser's input up-front. This is a bad fit for macro by example: when you parse `$e:expr`, you might consume only part of the input. However, today's trait-based solution doesn't really help -- we were already materializing the whole thing! So, let's keep it simple!
bors[bot] [Sat, 11 Dec 2021 22:58:49 +0000 (22:58 +0000)]
Merge #10951
10951: feat: assist to generate documentation templates r=Veykril a=numero-744
Closes #10878, #1915 and #4767
Full description is in #10878, better read [the tests](https://github.com/rust-analyzer/rust-analyzer/pull/10951/files#diff-7a64e2efb66b2625443340fcbc96d531baff12c17cc0aaf51885ea94f67de254R424) to understand what this feature does.
- [x] There is one remaining thing about non-`pub` functions, what do you think about it?
- [x] In this PR [empty examples are generated](https://github.com/rust-analyzer/rust-analyzer/pull/10951/files#diff-7a64e2efb66b2625443340fcbc96d531baff12c17cc0aaf51885ea94f67de254R99) for `trait` functions, but maybe no examples should be provided at all.
- [x] If there is already a documentation, add another one with a separator ([currently done](https://github.com/rust-analyzer/rust-analyzer/pull/10951/files#diff-7a64e2efb66b2625443340fcbc96d531baff12c17cc0aaf51885ea94f67de254R74)) or simply disable this assist?
- [x] I will check once more that the generated examples are correct (ie. they are easy to fill before that they are built and tested)
bors[bot] [Sat, 11 Dec 2021 14:58:07 +0000 (14:58 +0000)]
Merge #10956 #10986
10956: minor: Bump deps r=Veykril a=lnicola
bors r+
10986: fix: Fix lint completions not working for unclosed attributes r=Veykril a=Veykril
Fixes #10682
Uses keywords and nested `TokenTree`s as a heuristic to figure out when to stop parsing in case the attribute is unclosed which should work pretty well as attributes are usually followed by either of those.
bors r+
bors[bot] [Sat, 11 Dec 2021 14:49:29 +0000 (14:49 +0000)]
Merge #10877
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.
bors[bot] [Sat, 11 Dec 2021 13:50:55 +0000 (13:50 +0000)]
Merge #10976
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+
bors[bot] [Fri, 10 Dec 2021 22:31:55 +0000 (22:31 +0000)]
Merge #10978
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.
bors[bot] [Tue, 7 Dec 2021 16:52:21 +0000 (16:52 +0000)]
Merge #10960
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.
bors[bot] [Mon, 6 Dec 2021 09:50:49 +0000 (09:50 +0000)]
Merge #10949
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.
Aleksey Kladov [Sat, 27 Nov 2021 17:50:07 +0000 (20:50 +0300)]
feat: make hightlighting linear
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 :-)