Stream: t-compiler/rust-analyzer

Topic: Test references


vsrs (Oct 07 2020 at 19:30, on Zulip):

@matklad

There are two features that I think would be nice to have in RA:

And there are two difficulties:

The first problem is not so hard. We can use inverted n-gram index or inverted names (identifiers) index. I guess names index should work faster and would be quite enough as we do not need regex support. But I'll try both approaches.

The second one is more complicated. LSP allows to add CodeLens asynchronously, but RA does not use this ability, and to my mind, it requires significant internal changes to add it.

Do you have some thoughts \ ideas \ suggestions on this? Thanks.

matklad (Oct 12 2020 at 07:44, on Zulip):

This all sounds reasonable!

As usual, if we hide the feature behind a feature toggle, we can refine the impl as we go, no need to make it super fast right of the bat.

On the first point: We should have trigram index for speeding up reference search, but it requires some engineering effort to implement. We also need to check if trigram index is what actually is slow. My hunch here is that the slow thing is actually the semantic resolve, so it might make sense to profile it. IIRC, there are some low hanging frutits in the semantic resolve space. For example, we coupld classify potential match by syntax (field access, method call, path, pattern) and use that for some syntax-but-not-semantics quick filtering.

I also think that we effectively are already doing reference search to show "n references" code lens? If so, than the additional cost seems to be negligible?

On the second point: havan't looked into this, but, if there are async code lens, we should land a refactor to enable them!

vsrs (Oct 18 2020 at 10:23, on Zulip):

I'm sorry for the late reply.

We also need to check if trigram index is what actually is slow.

If I'm not mistaken at the moment we do full text search every time for each reference. If so, this can be accelerated.

My hunch here is that the slow thing is actually the semantic resolve, so it might make sense to profile it.

I'll try, though not sure that I know this part of the code good enough.

I also think that we effectively are already doing reference search to show "n references" code lens?

Actually I just reused existing mechanism, the same is used by rename_reference, etc. It works fast enough for n-references search, even for big projects like RA itself. But it too slow for tests search. I have a prototype and it takes up to 4-7 seconds to find all tests on my notebook. I'm sure it might be much faster.

but, if there are async code lens, we should land a refactor to enable them!

Perfect. Perhaps, this is where I should start.

Last update: Jul 29 2021 at 09:00UTC