search

microsoft / python-language-server

Microsoft Language Server for Python
Apache License 2.0
915 stars 133 forks source link

"Go to definition" functionality stops working #1913

Closed ashep closed 4 years ago

ashep commented 4 years ago

Environment data

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.

IMG

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 commented 4 years ago

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

CodeMonk commented 4 years ago

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

ashep commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@jakebailey, yes, it is multi-root.

jakebailey commented 4 years ago

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 commented 4 years ago

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

CodeMonk commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Sorry - I should have been more clear:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Works:

Broken:

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.

ashep commented 4 years ago

It seems switching to single-root workspace helped.

CodeMonk commented 4 years ago

My workspace is not multi-root . . . that I know of. There is only one directory in Project Manager plugin's config.

CodeMonk commented 4 years ago

Soooo - things are now working for me with the ms python language server. I have recreated my .pyenv, and I've also rebooted . . . . very strange.

I'll try to grab logs if I see it failing again, using the developer console

jakebailey commented 4 years ago

The developer console is the editor/extension and wouldn't contain stuff related to the language server itself (maybe some info about how they are handling our responses). You may or may not find something interesting there.

AFAIK this is still the same behavior as microsoft/vscode-python#5132, the overall issue with the way VS Code handles LSP requests to multiple language servers in multiple workspaces. Even if it's a single workspace, if the UI elements disappear then it could only be the extension or the editor itself causing the issue, as we have no control over what is shown in the UI; we declare that we support go-to-def and it's up to the client to send us a request.

CodeMonk commented 4 years ago

@jakebailey I want to confirm that I understand the vscode-python issue.

I generally run a vscode session in a django directory with an activated .pyenv virtualenv. Things work great, and I do not do multi-root workspaces.

However, I may open a file outside of my workspace with code but, those files are generally not related to my workspace.

I also, rarely, rebuild my .pyenv.

Could either of the above actions cause the language server to fail? And, once it has failed, is there a way to fix it? Restarting vscode has not helped in the past, but, I'm not 100% certain that I've actually restarted, and didn't have something keeping it from exiting completely (another window, etc)

If something can repair the broken server, I wouldn't mind doing it occasionally until the multi-root issues are fixed. (i.e. restarting vscode, restarting it from a new activated shell, etc)

jakebailey commented 4 years ago

So in general, the language server will throw away information about libraries to save memory. This means that the moment you leave your workspace and enter a file that's not "your code", the language server will fail to perform certain operations that have been dropped out of memory. This is expected behavior. #840

Also expected right now due to microsoft/vscode-python#5132 is that a multi-root workspace will not show any UI elements at all for features outside the workspace. To support multi-root workspaces and multiple LSs, the extension tells the editor "the python files within this directory go to this language server". This means that if a file is outside of those roots, then the editor will not tell any language server about the file and no functionality will work.

What's not expected is go-to-def-ing into a library file, it breaking, then coming back to the user code and it remaining broken. Your code in a workspace should always remain working.

ClericPy commented 4 years ago 
    "python.analysis.openFilesOnly": false,
    "python.analysis.memory.keepLibraryAst": true,
    "python.analysis.memory.keepLibraryLocalVariables": true,

These settings not work for me.

Process, close, Microsoft.Python.LanguageServer.exe

I run this autohotkey to kill LS process, waiting for it auto restart and goto works...

jakebailey commented 4 years ago

Making it (#840) work may require #1861.

jakebailey commented 4 years ago

1861 is merged. See my comment here: https://github.com/microsoft/python-language-server/issues/840#issuecomment-600907450

We'll see if this helps this specific case.

jakebailey commented 4 years ago

I traced this down; it's a bug in the extension around multi-root workspace support. I'll close this in favor of microsoft/vscode-python#11317 as I don't think we can do anything here.