"Go to definition" functionality stops working

[ashep]

Environment data

• VS Code version: 1.42.1
• Extension version (available under the Extensions sidebar): 2020.2.63990
• OS and version: GNU/Linux 5.5.4
• Python version (& distribution if applicable, e.g. Anaconda): CPython 3.8.1
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: None
• Relevant/affected Python-related VS Code extensions and their versions: None
• Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version vscode-python#3977): False
• Value of the python.languageServer setting: Microsoft

Expected behaviour

"Go to definition" functionality doesn't stop working.

Actual behaviour

"Go to definition" functionality stops working.

Steps to reproduce:

1. Use "Go to definition" on some object once.
2. After some time "Ctrl + Left Click" stops working, F12 doesn't work, "Go to definition" disappears from the context menu.

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

User belongs to experiment group 'AlwaysDisplayTestExplorer - control'
User belongs to experiment group 'ShowPlayIcon - start'
User belongs to experiment group 'ShowExtensionSurveyPrompt - enabled'
User belongs to experiment group 'DebugAdapterFactory - experiment'
User belongs to experiment group 'PtvsdWheels37 - experiment'
User belongs to experiment group 'UseTerminalToGetActivatedEnvVars - control'
User belongs to experiment group 'AA_testing - experiment'
User belongs to experiment group 'WebHostNotebook - control'
> conda --version
> pyenv root
> python3.7 -c "import sys;print(sys.executable)"
> python3.6 -c "import sys;print(sys.executable)"
> python3 -c "import sys;print(sys.executable)"
> python2 -c "import sys;print(sys.executable)"
> python -c "import sys;print(sys.executable)"
> ~/src/my/ampho/workbench/env/bin/python -c "import sys;print(sys.executable)"
> conda info --json
> ~/src/my/ampho/workbench/env/bin/python -c "import jupyter"
> ~/src/my/ampho/workbench/env/bin/python -c "import jupyter"
> ~/src/my/ampho/workbench/env/bin/python -c "import notebook"
> ~/src/my/ampho/workbench/env/bin/python -c "import notebook"
Starting Microsoft Python language server.
> conda --version
Starting Microsoft Python language server.

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)

https://www.dropbox.com/s/luc53x67qtfibcm/1582172224580.log?dl=0

[ashep]

Hi there! Any information about this issue? Thank you in advance.

[CodeMonk]

I've had to move back to jedi due to this behavior.

[ashep]

@CodeMonk, thank you for the suggestion. I'm going to try it in the nearest future. Can you tell me what's in your opinion is better: using Jedi or not?

[jakebailey]

After watching the OP's video, I'm not sure that it's the LS that's the problem here. We have no control over the UI, but the actual context menu items are disappearing, which is very strange. Is the original workspace multi-root?

[ashep]

@jakebailey, yes, it is multi-root.

[jakebailey]

This makes sense (in a way). You're jumping out to something outside the workspace, so the editor doesn't know which running language server to send the requests to, which is microsoft/vscode-python#5132. However, it shouldn't completely fail afterwards.

If you use a single root, this will probably go away, as now there's only a single LS running and all Python-related requests go to the same place.

[ashep]

@jakebailey, thank you, I'll try in a few days and report about results.

[CodeMonk]

That makes sense (multi-root discussion). I do run python from a pyenv for my django development. And, I do occasionally open files from outside of my repo / .pyenv

[CodeMonk]

@ashep Wrote

@CodeMonk, thank you for the suggestion. I'm going to try it in the nearest future. Can you tell me what's in your opinion is better: using Jedi or not?

I've used Jedi a lot in neovim, during the slow days, so, I'm not a real fan of jedi. And, the language server used to work REALLY well, even finding references from deep inside of libraries.

So, I guess I'm of the opinion that you should use jedi, if it works for you, until they fix the python language server. Least, that's what I'm going to do.

[jakebailey]

Note that in this instance, I don't even think switching analyzers will help, as the extension is going to spawn multiple things for multiple workspaces anyway, the oddity is in the behavior of VS Code, not any one analyzer (which all feed back to the same APIs).

@CodeMonk If there's something wrong with references deep inside libraries, that'd be something to report (or point to the issue you mean if it's already reported). #840 covers where we don't allow some features outside of user code, but bugs for things past that would be valuable to know.

[CodeMonk]

Sorry - I should have been more clear:

• Moving to Jedi completely fixed finding definitions for me.
• Finding those same definitions with the language server does not work.
• My reference to jedi not working right in neovim a long time ago was not really relevant. I have no idea how "good" it is in vscode.

Given the discussion above, I assumed that the failure(s) were related to the language server not using the .pyenv correctly after the multi-root changes.

I do not know of any strange behaviors other than Go to Definition not working unless you use jedi instead of the Microsoft Python Language Server.

[CodeMonk]

So, using jedi also disables the ability to search for a symbol in workspace. I am NOT running multi-root, but, I do have a django app.

[jakebailey]

If you have an issue with Jedi in the VS Code extension, I suggest asking on the extension's issue tracker. Jedi/MPLS are mutually exclusive, and the extension must provide all of the info Jedi cannot separately.

[CodeMonk]

That was simply a data point for whoever is looking into the issue.

Works:

• Jedi + F12 on a symbol.
• python LS + Go To Symbol in Workspace

Broken:

• Jedi + Go To Symbol in Workspace
• python LS + F12 on a symbol

I never suggested that this issue was tasked with fixing anything in Jedi. I simply pointed out, more specifically, what things work and do not work for me.