Roslyn: Go to All and Find All References deduplication improvements

[jnm2]

^{Moving the conversation @NickCraver started from Twitter at @davkean's request.}

VS2017's Go to All and Find All References duplicates items for each platform or framework you're building against. If you build for six platforms, every member shows up six times but takes you to exactly the same point in the same document. It's pure noise which limits what else you can see in the list.

For example, using @NickCraver's screenshots:

The items should be grouped by destination. The information that is unique to each entry (the framework) should be shown in small print underneath. Only one thing should be clickable for all platforms, unless there are signatures in different physical files or positions due to csproj conditional file includes or #if preprocessor. One navigation destination, one entry.

This would be amazing (pardon my MS Paint):

[NickCraver]

Related here, there' a search bug I noticed in capturing these. Note what happens I enter T right after a < in the search, certainly not expected behavior:

...with a T goes to:

If I had to guess it seems like the < is ignored completely, and then T is pressed it's actually searching for QueryT? Maybe not, just a guess. Should I file another issue on that? I'm not sure if this is search or Roslyn or both or...

[jnm2]

@NickCraver My guess is separate issue.

[CyrusNajmabadi]

PRs welcome

[CyrusNajmabadi]

We don't support any sort of special syntax for generic types. Note that we're also moving our pattern matching code down to the platform layer (so all managed languages in VS could use it). As such, it gets even more difficult to put in support for matching all the sorts of special constructs that could be different across languages.

[NickCraver]

That's unfortunate, searching for a generic is a very common case here. A specific usage, or , etc. Reverting to text find for all those cases really is very frustrating since I can see the results just down the list...but a text find is often faster than going through it.

I'm unfamiliar with VS tooling, really not a good use of my time (compared to libs for the community), but I hope someone more familiar is able to tackle this. I'd readily test away on any bits.

[jnm2]

@NickCraver This is definitely two separate issues though.

[NickCraver]

@jnm2 yeah totally fair - I'll at least file this out, un momento.

[jnm2]

@NickCraver loop me in please? I have an idea that I'll add.

[jnm2]

I added this issue to my PR wishlist, so maybe I'll get around to this in a year if no one beats me to it. 😝

[NickCraver]

Filed as an issue in https://github.com/dotnet/roslyn/issues/19380

[CyrusNajmabadi]

It's literally a matter of matching the text of the items that show up in the list. Instead of just indexing the name, you could index the display text.

It's really not that simple :)

(trust me, i've written and rewritten this system several times). For one thing we don't want symbols to be generated when producing the index. So we don't have a context of 'DisplayText'.

Furthermore, this gets deeply complex due to the fact that different languages have different symbolic representations for these things. For example, say you wrote the type in VB, but you want to search for it in C#.

Finally, if we did 'index' this then we'd have to be careful about negative fallout. For example, if we index Query<T> (in some fashion), but then the user searched for Query, people would still want that to be considered an 'Exact' match, and thus better than, say, QueryBlah. But because the query string didn't match the indexed string, it would now be considered a 'Prefix' match.

The index could also store several forms. but then you have to worry about index size and how much extra memory that might use. etc. etc.

[Pilchie]

The FAR issue is already tracked as https://github.com/dotnet/roslyn/issues/16587. I'm going to close this as a dupe, but update the original issue to point out that it affects Go To as well.