SymbolFinder.FindReferencesAsync is missing a reference to a type used in a document with implicit declaration only

[SENya1990]

Hi everyone.
I encountered an issue with Roslyn reference search API. I'm writing stand alone console analyzer which tries to collect usages of a type outside of its declaring assembly. Accidentally, I encountered that in some specific cases results of a call to SymbolFinder.FindReferencesAsync are missing a reference. Moreover, I found that Visual Studio also can't find references correctly - it has the same reference missing.

Version Used:
I used the latest published Roslyn nugets:
Here are my installed nuget packages:

<ItemGroup>
    <PackageReference Include="Microsoft.Build.Locator" Version="1.2.6" />
    <PackageReference Include="Microsoft.CodeAnalysis" Version="3.8.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.1">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.8.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="3.8.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.VisualBasic.Workspaces" Version="3.8.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Workspaces.Common" Version="3.8.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Workspaces.MSBuild" Version="3.8.0" />
  </ItemGroup>

The issue can be reproduced in Visual Studio. I'm using Visual Studio Professional 16.7.7

Steps to Reproduce:
I reduced the example code to a very small solution on which Roslyn has the same behavior.

1. Create a new solution with console app project. Define a new class Input in a separate file:

public class Input 
{
}

2. Define a new class InputReader in a separate file:

 public class InputReader
 {
        public Input ReadInput(string[] input) => new Input();
 }

3. In the Main method in the Program class add the following code:

class Program
{
	static void Main(string[] args)
	{
		var reader = new InputReader();
		var input = reader.ReadInput(args);

		Console.WriteLine(input.ToString());
	}
}

4. Search for Input class references either in Visual Studio or with the following code (I use MSBuildWorkspace to load solution):

using (MSBuildWorkspace workspace = MSBuildWorkspace.Create())
{			
	string solutionPath = @"<path to solution>";
	var solution = await workspace.OpenSolutionAsync(solutionPath);
	var proj = solution.Projects.First();
	var compilation = await proj.GetCompilationAsync();
	var symbol = compilation.GetTypeByMetadataName("SomeNamespace.Input");
	var references = await SymbolFinder.FindReferencesAsync(symbol, solution);       //Examine references to "Input" type
}

Expected Behavior:
I expect that results of reference search will contain a reference to the var input in the Main method.

Actual Behavior:
Unfortunately, there is no reference to the var input in the Main method. However, if I use explicit typing instead of var keyword there will be a reference! It seems for Roslyn that there is a difference between implicit and explicit variable declarations.

I wrote my own custom IFindReferencesProgress reporter and found out that Program.cs file is completely not searched. Internally it is not included to a set of documents which should be searched.
I investigated the code with debugger a little and found out that the exclusion happens in AbstractReferenceFinder type in
FindDocumentsAsync method:
http://sourceroslyn.io/#Microsoft.CodeAnalysis.Workspaces/FindSymbols/FindReferences/Finders/AbstractReferenceFinder.cs,101

 return FindDocumentsAsync(project, documents, async (d, c) =>
            {
                var info = await SyntaxTreeIndex.GetIndexAsync(d, c).ConfigureAwait(false);
                
                  //This parts in my opinion adds AssemblyInfo and some other compiler generated Documents to the search
                if (findInGlobalSuppressions && info.ContainsGlobalAttributes) 
                {
                    return true;
                }

                foreach (var value in values)   //Here 'value' is the string name of a type, in my case it is "Input"
                {
                    // Here if I understand correctly is a check which internally use BloomFilter to see if the document
                    // definitely should not be searched.
                    // I'm not sure but I think it works on strings and does not consider implicit declarations
                    if (!info.ProbablyContainsIdentifier(value))   
                    {
                        return false;
                    }
                }

                return true;
            }, cancellationToken);

[CyrusNajmabadi]

I expect that results of reference search will contain a reference to the var input in the Main method.
It seems for Roslyn that there is a difference between implicit and explicit variable declarations.

This is out of scope for find-references. It finds direct literal references, not inferred references. You hit the nail on hte head with that observation.

Another way to think about this is that it would be the set of things that would need to be updated if the name of the entity changed. That doesn't happen with 'var', so it's not given in the result.

While the request is understandable, it's also not feasible. Find-References depends heavily on being able to examine a massively smaller subset of possibilities in the system. If we had to examine all 'var' references, we would effectively have to search every single file (and hundreds to thousands of possibilities per document). This would be far too expensive and would make FindReferences take ages.

--

Note: you can do this search yourself. It will be expensive as you will have to check all the 'var's yourself. But that's no worse than what we would be doing.

Good luck!

[CyrusNajmabadi]

If you know a piece of documentation where this behavior is described I will really appreciate if you provide it to me.

I know of no such documentation. I think it would be reasonable though if you wanted to file a documentation issue to ask for this to be clarified.

[CyrusNajmabadi]

However, it greatly confuses me.

Can you clarify which part you find confusing? I mentioned above the general philosophy this takes. Namely, you could imagine it answering the question: "what are all the places in the code i would actually need to update if i changed the name of this entity?". These are the explicit places in the code where the symbol is used. There are also many place where symbols are implicitly used, but which would likely be enormously unpleasant to get references for. For example, any temporary values of that type. You would also get references to every 'this' reference for a type when searching for the type itself.

This would not only be very cluttered and useless the vast majority of times, it would also be too expensive here. As you've garnered from the implementation, we are only able to make this reasonably fast if we have a way to narrow down the set of things we're looking at. In the case of implicit/temporary/conversions, there's nothing for us to use to do that narrowing, so we would have to examine everything in the system. That would likely increase processing time by 1-3 orders of magnitude at a minimum.

As mentioned above, if you need this for your own purposes, the only solutoin is to do the search yourself. We have no means at our disposal to do anything better for you on your behalf. A find-refs that finds implicit references will just have to check everything, and see if it's a match.

[SENya1990]

Thanks again for the clarification.
It seems that I had a different understanding of the term "reference". I thought that reference to a type means the usage of a type, not just direct usage of the type by its name. I probably have never noticed it directly before. I certainly would like a separate "Find all usages" long run search in Visual Studio. It seems this was addressed in #24905.

In my opinion the term "reference" is not precisely defined in the documentation. Or I just missed the correct documentation for it.
It seems that its meaning is not obvious. My naive understanding of "reference to a type" was that the term applies to both explicit and implicit declarations of a local variable.

It was also unexpected to have a different behavior of reference search for implicit variable declarations since I used to think that there is semantically no difference between explicit and implicit declarations. I know that there is no difference from the language point of view but I think the difference in the IDE behavior is also important. This behavior will definitely affect my choice between implicit and explicit declaration in the future.

Again thanks for your help. I would like to create a request to make documentation of the reference search more detailed by including a precise definition of the term "reference". I just don't know what steps I should do to create such request.
If it is possible I would also request to add to the documentation the description of the difference in the behavior of VS for implicit variable declarations. I didn't find it in the following articles:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/var
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/implicitly-typed-local-variables
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/how-to-use-implicitly-typed-local-variables-and-arrays-in-a-query-expression

[CyrusNajmabadi]

In my opinion the term "reference" is not precisely defined in the documentation.

Correct. It's just generally an intuition. I don't think we'd strongly define it either as that would lock us into a particular implementatino/result strategy. We may absolutely change this in the future if we replaced our existing system with an entirely new system based on different concepts.

My naive understanding of "reference to a type" was that the term applies to both explicit and implicit declarations of a local variable.

Sure. As i mentioned, your intuition is fine and understandable. It's just not what we provide (for many reasons). The intuition here is more like "if i changed this name, what would need to be updated". Clearly, implicit things don't need to be updated as they're not actually a 'use' from teh user.

I used to think that there is semantically no difference between explicit and implicit declarations.

I used to think that there is semantically no difference between explicit and implicit declarations.

There is no semantic difference. But there being no semantic difference doesn't mean all our features work the same way. Our features operate at the level of teh source-code and what we can do with it. We don't operate at the level of final semantics.

Consider something as simple as 'formatting'. Clearly, formatting is going to care how you wrote this. It will view int x = y; foo(x); as different from foo(y). The same is true for 'find refs'. If you're doing find refs on int, we're not going to show a result for foo(y) despite it being semantically teh same as int x = y; foo(x);.

Being semantically the same doesn't really have a bearing here.

[CyrusNajmabadi]

I didn't find it in the following articles:

Those are all articles about the language. They don't have any bearing on IDE features. The docs for this would likely be here: https://docs.microsoft.com/en-us/visualstudio/ide/finding-references?view=vs-2019

However, as i mentioned before, while we might mention this as the behavior, it's unlikely we would spec this as we reserve the right to change this impl at any time based on how much value we see, and what the costs are involved here. For example, if we entirely change our compiler implementation (as we did with Roslyn), we may find that we are unable to do something we previously were able to do, or we're now able to do something we previously couldn't (indeed, that is absolutely what happened with FindReferences when we reimplemented everything).

[jbhaywood]

Totally agree with @SENya1990. This is far from a useless scenario. I just spent more time than I should have trying to figure out why SymbolFinder.FindReferencesAsync wasn't returning what I thought it should. I had a suspicion that there was some kind of technical difference between a "reference" and a "usage" but also couldn't find any documentation to verify that, outside of this one thread. I wouldn't mind waiting for a long running process if I knew it was going to return everything I need. Is the code behind VS's "Find Usages" command open sourced anywhere?

[CyrusNajmabadi]

Yes. The code is entirely in Roslyn.

SymbolFinder.FindReferencesAsync

You can find this code (and everything it references) within this repo. Feel free to play around with expanding the set of matches to all implicit ones.

This would be doable by having the individual "IReferemceFinder"s return all documents as a place to look for references. Then walking reach and every tree, getting full semantics on every node and checking them all deeply if there is a reference you care about.

[CyrusNajmabadi]

This is far from a useless scenario

Note, at no point has it ever been claimed that this is a useless scenario.

[jbhaywood]

Thanks. I realize that the code behind SymbolFinder.FindReferencesAsync is here, but I was wondering if the code behind Visual Studio's "Find All References" command, that you mentioned was an IDE feature (which is understandable) and pointed to here was open sourced.

[CyrusNajmabadi]

Yes. That code is in Roslyn as well (not at computer so can't point to it right now). It is what open source. It simply sits on top of these apis and displays the results