Tooltip and Go To Definition confused by multiple overloads

bgrommes

Given these method signatures in a module named Path:

Path.Combine(String,String)
Path.Combine(String,String,String) # calls Combine(String,String) on some code paths
Path.Combine(String,String,String,String) # calls Combine(String,String,String) on some code paths
Path.Combine(ParamArray values() As String) only called for < 2 or 5+ arguments, doesn't call other overloads

... the following problems obtain:
1) The tooltip on hover over the Combine(String, String) call in Combine(String, String, String) describes the variadic overload and gives the description from the 4-argument overload (it doesn't matter if I use Path.Combine or just Combine):

2) Same thing if you hover over the Combine(String,String,String) call in Combine(String,String,String,String).
3) If you right click on Combine(String,String) and select Go To Definition, it takes you to Combine(String,String), but if you right click on Combine(String,String,String) and select Go To Definition, it still takes you to Combine(String,String).
4) For the heck of it I put this into the variadic overload:

If 1 = 2 Then
  Combine(values[1], values[2], values[3])
End If

This produced the error, "Unidentified identifier 'Combine'" "Unidentified function 'Combine'". I changed it to Path.Combine and then the error went away, but the tooltip behavior and the Go To Definition behavior was the same as described above: the tooltip described the variadic overload and gave the description / remarks for the 4 string overload, and Go To Definition takes you to the two-string overload.

So I assume that Go To Definition wrongly selects the first overload, while the tooltip conflates the variadic with the 4-argument overload for some reason.

If all that gave you a headache, consider us even!

Garry

Thanks for the excellent report. Your diagnosis was essentially correct. There were three related bugs:

The tooltip identified a method by its name but did not use the arguments at the call site to determine which overload had been selected. It therefore displayed whichever overload appeared first internally (often the ParamArray overload).
Documentation was stored against the method name rather than the complete signature. This allowed the description from one overload to be displayed alongside another overload’s signature.
Go to Definition carried only the method name and kind to the editor. With several functions sharing that name, the editor selected the first one instead of the overload used by the call.

I've fixed all three. Objo Studio now uses the compiler’s overload-resolution result for tooltips and navigation. The selected overload appears first in the tooltip, each overload retains its own documentation, and Go to Definition opens the exact declaration. I also corrected the compiler’s overload ranking so that a matching fixed signature is preferred over a compatible ParamArray fallback, consistent with runtime dispatch.

The unqualified Combine(...) call inside the module is separate and remains expected behaviour under the current language rules. Modules are static containers, so the call should be qualified as Path.Combine(...).

https://feedback.objo.dev/bug/914