Empty MethodCalls on Some Scenarios

[timmyteo]

When running Dosai with the Dosai source code as the inspection input, the resulting output JSON has an empty array of objects for the property MethodCalls. This is unexpected and it seems that because of the way the code is written, that Roslyn is throwing an error (see attached screenshot). The goal of this issue is to potentially identify the bug and fix it so that the MethodCalls populates when inspecting the Dosai code.

[prabhu]

@timmyteo Got the below response from Gemini Experimental 1206. We can see that there is a CandidateSymbols which apparently could be iterated. Any thoughts?

---

The OverloadResolutionFailure reason, along with SymbolInfo in your exprInfo, when parsing C# code with Roslyn, indicates that the compiler was unable to determine which method or property to use when encountering a call or access with multiple potential candidates. This essentially means there's ambiguity in your code that Roslyn can't resolve on its own.

Here's a breakdown of the common causes and how to troubleshoot them:

Common Causes of OverloadResolutionFailure

1. Ambiguous Method Calls:

   • Multiple methods with the same name and similar parameter types: If you have several methods (overloads) with the same name and parameters that are close enough in type, the compiler might not be able to figure out the best match based on the arguments you're providing.
   • Implicit conversions causing conflicts: If the types of your arguments can be implicitly converted to multiple parameter types of different overloads, the compiler might get confused.
   • Optional parameters and default values: Complex scenarios with optional parameters and default values can sometimes lead to ambiguity.
   • Extension methods: Multiple extension methods with similar signatures might create conflicts.
   • params keyword: Using params for variable argument lists can also lead to ambiguity if not used carefully.

   Example:

   public class MyClass
   {
       public void MyMethod(int a, string b) { /* ... */ }
       public void MyMethod(double a, string b) { /* ... */ }
   
       public void Test()
       {
           MyMethod(5, "hello"); // Ambiguous: 5 can be int or double
       }
   }

2. Ambiguous Property/Indexer Access:

   • Similar to method calls, if you have properties or indexers that could match based on the context, ambiguity can arise.

3. Missing or Incorrect References/Usings:

   • Missing references: If the assembly containing the type with the method you're trying to call isn't referenced by your project, Roslyn won't find it.
   • Incorrect using directives: If you're using types from different namespaces and don't have the correct using statements, Roslyn might not be able to resolve the correct type.

4. Type Inference Issues (Especially with Generics):

   • In some complex generic scenarios, the compiler might fail to infer the correct type arguments, leading to OverloadResolutionFailure.

5. Accessibility Issues:

   • If the method or property you're trying to call isn't accessible (e.g., it's private and you're calling it from outside the class), this can also contribute to the problem. Although there should be a different error type, this could happen depending on what version of Roslyn you're using.

Troubleshooting Steps

1. Examine the Code Context:

   • Identify the line and expression causing the error: The exprInfo (or related error details) will usually point to the specific location.
   • Look at the available overloads: Carefully check the signatures of all the potential methods, properties, or indexers that could be called at that point.
   • Inspect argument types: Make sure you understand the exact types of the arguments you're passing or using in the expression.

2. Explicitly Specify Types or Casts:

   • Type casts: If there are implicit conversions causing conflicts, add explicit casts to guide the compiler:

     MyMethod((int)5.0, "hello"); // Force 5.0 to be treated as an int

   • Fully qualified names: If there are namespace clashes, use the fully qualified name of the type:

     MyNamespace.MyClass.MyMethod(...);

3. Refactor for Clarity:

   • Rename methods or change parameters: If the overloads are genuinely very similar, consider renaming them or adjusting the parameters to make them more distinct.

   • Use named arguments (if applicable): For methods with many optional parameters, use named arguments to be explicit about which parameters you're providing.

     MyMethod(b: "hello", a: 5);

4. Check References and Usings:

   • Verify project references: Ensure that your project correctly references all necessary assemblies.
   • Add missing using directives: If you're using types from namespaces you haven't imported, add the appropriate using statements.

5. Provide Explicit Type Arguments (for Generics):

   • If you're dealing with generics, explicitly specify the type arguments to help the compiler:

     MyGenericMethod<int, string>(...);

6. Review Roslyn API Usage

   • Check the SemanticModel: Ensure you're obtaining the SemanticModel correctly and that it's associated with the correct syntax tree and compilation.
   • Verify compilation options: Double-check any custom compilation options you might be using that could affect type resolution.

7. Get Symbol Information from the Semantic Model:

   • SymbolInfo Structure:
     • SymbolInfo is a structure returned by methods like GetSymbolInfo, GetTypeInfo, and GetDeclaredSymbol on the SemanticModel.
     • It provides information about the symbol(s) resolved at a specific syntax node.
   • Key Properties:
     • Symbol: Returns the resolved ISymbol if a single symbol was found unambiguously.
     • CandidateSymbols: Returns an ImmutableArray containing all potential symbols that could match at that location (in cases of overloads or ambiguity).
     • CandidateReason: An enum value of type CandidateReason that explains why a particular candidate was considered or why no symbol was found.

   Code Example:

   // Assuming you have the SemanticModel (semanticModel) and SyntaxNode (node)
   
   SymbolInfo symbolInfo = semanticModel.GetSymbolInfo(node);
   
   if (symbolInfo.Symbol != null)
   {
       // A single symbol was resolved
       Console.WriteLine($"Symbol found: {symbolInfo.Symbol}");
   }
   else if (symbolInfo.CandidateSymbols.Length > 0)
   {
       // Multiple candidates were found
       Console.WriteLine("Candidate symbols:");
       foreach (ISymbol candidate in symbolInfo.CandidateSymbols)
       {
           Console.WriteLine($"- {candidate} (Reason: {symbolInfo.CandidateReason})");
       }
   }
   else
   {
       // No symbol was found
       Console.WriteLine($"No symbol found. Reason: {symbolInfo.CandidateReason}");
   }

Example Scenario and Debugging

Let's say you have this code:

public class Example
{
    public void DoSomething(int x) { }
    public void DoSomething(double x) { }

    public void Test()
    {
        DoSomething(5); // Ambiguous!
    }
}

And you get OverloadResolutionFailure on the DoSomething(5) call.

Debugging:

1. You see that there are two DoSomething methods.
2. The argument 5 is an integer literal, which can be implicitly converted to both int and double.
3. Solution: You can either cast 5 to (double)5 if you intend to call the double version, or do nothing to call int version, or rename the methods to avoid ambiguity.

In Summary

OverloadResolutionFailure in Roslyn means the compiler is stuck because your code is ambiguous. By carefully examining the code, using explicit type specifications, and refactoring when necessary, you can resolve these ambiguities and help Roslyn understand your intent. Remember to leverage the diagnostic information provided by Roslyn (e.g. use GetSymbolInfo method) to pinpoint the exact cause of the problem.

[timmyteo]

The explanation makes sense. The screenshot on this issue does show the OverloadResolutionFailure example and the CandidateSymbols attribute is populated with what appears to be the ambiguous method. So it seems possible that when this error comes, additional logic could process the candidate details and at least extract some information, which is better than ignoring this case as it presently does.