Add IMethodGroupReferenceOperation

[MarkKharitonov]

Background and Motivation

Please, see #76616.

Consider the following source code:

public class Type1
{
    public static void f(){}
}

using static Type1;
using Type3 = Type1;
public class Type2
{
    public static string X = nameof(f);
    public static string Y = nameof(Type1.f);
    public static string Z = nameof(Type3.f);
}

It demonstrates three different way to express the same nameof semantics. An important detail - the argument of nameof is a method group:

1. Type1.f - fully qualified through its parent type Type1
2. Type3.f - fully qualified through an alias Type3
3. f - unqualified, imported into the scope by the using static Type1 directive.

Inspecting the INameOfOperation yields different results for the third case as explained in great detail in the aforementioned issue.

Proposed API

Seems like the only case that needs special attention is when the argument of the nameof operator is a method group. Hence the idea is to introduce something like IMethodGroupReferenceOperation:

namespace Microsoft.CodeAnalysis.Operations
{
     public class IMethodGroupReferenceOperation
     {
         public INamedTypeSymbol ContainingType { get; }
         public string Name { get; }
     }
...
}

[CyrusNajmabadi]

@333fred for thoughts.

[333fred]

@MarkKharitonov, good start. However, there's more information to capture here. This type of API needs to be the equivalent of something like GetSymbolInfo, where it returns all the possible candidates that were considered, and potentially why none was chosen. It would be useful go through the properties of BoundMethodGroup (in both C# and VB) and list out the properties they have in common, so that we can look at which of those pieces of information we want to expose. This is also technically a duplicate of #19965, but I'll close that one in favor of this one, as you can't edit the first post of that issue.

[MarkKharitonov]

I do not have much experience designing Roslyn APIs.

Given my current state of knowledge, I have a feeling that the proposed API is already useful, albeit minimal. I do not think it contains anything redundant and it is possible to enrich it in the future with more features in a backwards compatible manner.

Please, correct me if I am wrong.

[CyrusNajmabadi]

@MarkKharitonov The APIs are not designed based on the need of a particular consumer. The APIs here are more about practically exposing the real way the compiler views these language constructs across VB/C#. I'd recommend taking what Fred said into account here. For example, here are the APIs for BoundMethodGroup for boht VB and C#: https://github.com/dotnet/roslyn/blob/main/src/Compilers/CSharp/Portable/BoundTree/BoundMethodGroup.cs
https://github.com/dotnet/roslyn/blob/main/src/Compilers/VisualBasic/Portable/BoundTree/BoundMethodGroup.vb

It would also make sense to see how we've exposed the concept of a group of members elsewhere to ensure consistency there.

[333fred]

Given my current state of knowledge, I have a feeling that the proposed API is already useful, albeit minimal. I do not think it contains anything redundant and it is possible to enrich it in the future with more features in a backwards compatible manner.

Well, for example, ContainingType isn't something we can expose directly on this API. A method group might have methods from multiple different types, either through inheritance, or through extension methods with different receiver types. Only by examining the different possible methods chosen can you determine what the containing type of an individual member would be.