- 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[bot] [Thu, 11 Nov 2021 13:45:20 +0000 (13:45 +0000)]
Merge #10743
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>
bors[bot] [Wed, 10 Nov 2021 21:08:51 +0000 (21:08 +0000)]
Merge #10689
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.
bors[bot] [Wed, 10 Nov 2021 15:12:05 +0000 (15:12 +0000)]
Merge #10738
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+
bors[bot] [Tue, 9 Nov 2021 22:11:32 +0000 (22:11 +0000)]
Merge #10731
10731: fix: show the right check-command r=Veykril a=Florian-Schoenherr
Currenty r.a. only shows this:
even if another command was specified
bors[bot] [Sun, 7 Nov 2021 11:13:15 +0000 (11:13 +0000)]
Merge #10699
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).
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+
bors[bot] [Fri, 5 Nov 2021 13:53:59 +0000 (13:53 +0000)]
Merge #10703
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+
It feels wrong using the database in this part of the code, but this was the only way to figure out whether a file belongs to a proc-macro that I could think of.
For `-gnu` triples, use 20.04, the current LTS. This upgrades the
required version of glibc. For musl, just use `latest` as, presumably,
we don't care about glibc version in that case.
Aleksey Kladov [Sun, 31 Oct 2021 10:05:40 +0000 (13:05 +0300)]
feat: upgrade ubuntu builders
For `-gnu` triples, use 20.04, the current LTS. This upgrades the
required version of glibc. For musl, just use `latest` as, presumably,
we don't care about glibc version in that case.
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:
> 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:
_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.
projects / rust.git / log