[MS Language Server] Go to definition control only appears on primary workspace

[amittleider]

Sometimes the Go to definition function will not appear in your VSCode if you have multiple workspaces and use the MS Language Server. You will only see the "Go to definition" function available if you are within the workspace that was active when you originally opened VSCode. Other workspaces will not have the Go to Definition function available.

Let me give an example to be clear:

• Go to this repo: https://github.com/amittleider/vscode_multi_workspace_bug_repro
• Check out the branch go_to_definition_primary_workspace

1. Example 1 - You can "Go to definition" in the upper_level_project workspace

• Go to upper_level_class.py and reload VScode.
• When VSCode comes back up, you should be able to right click and see that "Go to definition" is available.
• Switch to the file level_2_class.py.
• Right click on the class Level1Class and you will notice that there is no "Go to definition" button available to you.

2. Example 2 - You can "Go to definition" in the level_2_project workspace.

• Go to the file level_2_class.py and reload VSCode
• When VSCode comes back up, you should be able to right click and see that "Go to definition" is available.
• Switch to the file upper_level_class.py
• Right click on the class Level2Class and you will notice that there is no "Go to definition" button available to you.

Below is a gif of the described behavior.

Environment data

• VS Code version: 1.35.0
• Extension version (available under the Extensions sidebar): 2019.5.18875
• OS and version: Ubuntu 18.04
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.7 64 bit
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Language Server (more info How to update the language server to the latest stable version #3977): Language Server

[MikhailArkhipov]

The issue is not a bug. LS only supports single root, it is not capable of handling multiple roots, especially with different versions of Python. Extension (and Visual Studio) runs multiple LS processes, one for each root (or project in solution in VS). Said instances are not able to communicate or navigate across tree spanning multiple processes. Making LS actually load multiple roots would a major architectural redesign. Thus the issue is that not that someone made a mistake (i.e. a bug) but rather conscious architectural design limitation.

[luabud]

Closing in favour of #5132.