Find References, but filter tests

[PSeitz]

I usually use find references to get an understanding of the code, where the dependencies are and what a call-stack looks like.
rust-analyzer references is really helpful there, but one issue is that it is cluttered with references from tests. It would be nice to add a option to filter references from tests.

[st3fan]

Looking at the Find References Request documentation, it seems that it just takes a text location and then returns a list of references. There is no concept of filtering or context in the LSP protocol.

That makes me think that this is something that should be implemented in the editor instead?

(FWIW I find this specific request really interesting because in my day to day work I often run into these kind of wishes where my editor (Helix in my case) follows LSP to the letter and exposes the protocol really nicely, but where I really want something on top of that, similar to this request. Like for example "Find references to this in the files I have open" or "Find references to this in files recently changed". I think there are some really big opportunities to do some cool things that go beyond just supporting the LSP protocol.)

[xiaochuanyu]

There already some amount of logic in the code that categorize references:

rust-analyzer/crates/ide-db/src/search.rs

Lines 66 to 76 in feefbe7

	#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
	pub enum ReferenceCategory {
	// FIXME: Add this variant and delete the `retain_adt_literal_usages` function.
	// Create
	Write,
	Read,
	Import,
	// FIXME: Some day should be able to search in doc comments. Would probably
	// need to switch from enum to bitflags then?
	// DocComment
	}

I also miss this feature when working rust. IntelliJ for example can show usages grouped by read/write, prod/test etc..
I'd like to take a stab at implementing this but I'm still learning the code base and this doesn't look very easy (to me).

[Veykril]

The current system for that won't work too well. ReferenceCategory is exclusive, in that only one kind can be used. Being part of a test annotated function/module doesn't exclude something from being also Write, or an Import etc. This probably needs to be changed to a bitflags structure. So yes this is a bit more involved.

[PSeitz]

There's also related tests, which could be used in some variant maybe

[PSeitz]

A workaround could be to run rust-analyzer temporarily with the test feature disabled, so the #[cfg(test)] blocks would be ignored