Go to implementation (Ctrl+F12) is broken for interface async methods

[vsfeedback]

I defined an interface with async methods in a .Net Standard 2.0 project. And two implementations in two .Net Core 2.1 projects.
When I press Ctrl+F12 over the interface name, the Visua Studio 'implementations' window displays the two implementations.
But when I press Ctrl+F12 over a method whose implementation has async keyword method, it doesn't find any implementation, presenting a dialog into saying "This symbol has no implementations".
The expected result is that the 'implementations' window should present the two implementations of the method.

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/295266/go-to-implementation-ctrlf12-is-broken-for-interfa.html
VSTS ticketId: 649802
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

[paulovila]

Hi @jinujoseph is there any progress with this bug?

[jinujoseph]

@paulovila not yet , it's in our list todo

[paulovila]

Hi @jinujoseph Any time this year?

[CyrusNajmabadi]

@paulovila Would you be interested in contributing a fix here?

[paulovila]

Definitely, I'd be glad to help, my email is []

[CyrusNajmabadi]

Great! I'd recommend starting with: https://github.com/dotnet/roslyn/wiki/Building-Testing-and-Debugging

When you've gotten to a buildable state, let me know. Thanks!

[paulovila]

I’ve have Roslyn compiled, where should I go next?.
Regards, Paulo

[CyrusNajmabadi]

Hi @paulovila ! First, if you fully build and then hit f5 that should launch another instance of VS that you can debug from the VS you're in. Within that VS try to repro the scenario (i.e. ctrl-f12). This will tehn let you hit breakpoints you can set up in teh main VS. i recommend starting in GoToImplementationCommandHandler.ExecuteCommand. That's a good starting point to start debugging through to see at what point things start failing.

Let me know if htat's enough to go off of. Thanks!

[ryzngard]

The problem comes in because the types and namespaces are equivalent up through the global namespace, but the ContainingSymbol for each global namespace is different. One is NetModule System.Runtime.dll and one is NetModule netstandard.dll when calling AreEquivalentWorker.