Neovim telescope lsp_references, lsp_document_symbols, lsp_definitions not working

[martin-scheele]

Hello! First of all, thanks for the awesome work being done here. Hopefully this is the right place to ask for help/clarification regarding this - as far as I can tell, this isn't an issue with other plugins (i.e. Telescope) or with my configuration per se, granted I could be wrong about that.

I'm using neovim and have basedpyright installed and configured through mason and mason-lspconfig.

I'm running into some issues with a few of the language server features. I'm using telescope pickers for the "goto _" functionality (e.g. the :Telescope lsp_references command), and this has worked with every other language server I've come across.

With based_pyright, however, the Telescope windows come up blank for lsp_references, lsp_document_symbols and lsp_definitions specifically. lsp_definition does work on user defined objects, but nothing comes up for Python builtins.

The vim.lsp.buf.references, vim.lsp.buf.document_symbol and vim.lsp.buf.definition functions work as expected.

I don't really have a good enough understanding of what is going on under the hood to be able to understand where the problem actually lies. Any clarification on this would be greatly appreciated, and if this is some simple oversight or misunderstanding on my part or if there is any further information needed, please let me know.

[DetachHead]

I don't really have a good enough understanding of what is going on under the hood to be able to understand where the problem actually lies.

unfortunately since i'm not a neovim user i'm in the same boat lol. some ideas to try to help narrow down where the issue is:

• lsp_definition does work on user defined objects, but nothing comes up for Python builtins.

  this sounds a lot like #649, which was fixed recently. what version of basedpyright are you using?

• does it also happen in pyright? or only basedpyright?

• are you able to check if you have similar issues in one of the other supported editors?

[martin-scheele]

Mason has the most recent version of basedpyright (1.17.5).

I haven't tested it with pyright or another editor but I can test that sometime in the next few days.

Oddly enough, I just tested the functionality again in a different Python project and somehow references and document symbols started working, but definitions for the Python builtins are still broken. The two projects are configured identically so I'm not sure what's going on there either. I can test it some more this week and report back with whatever I can figure out.

Again, thanks for taking the time to give me some leads on this! I really appreciate it.

[martin-scheele]

I just got around to testing this - the issue isn't present in the VSCode extension, nor in neovim using pyright.

At the end of the day its something I can work around, but I am curious as to where the issue actually stems from.

[DetachHead]

can you set basedpyright.analysis.logLevel to "Trace" and see if it logs anything noteworthy?

[martin-scheele]

Not quite sure what's going on but I'm not getting any logs for basedpyright, at least not in the neovim lsp.log file (it's working for other servers though).

[DetachHead]

maybe basedpyright isn't even running? are you seeing any type errors? can you verify whether any of the basedpyright-exclusive features are working?

[martin-scheele]

Yeah, I mean everything is working in at least some projects - I think I'll try installling basedpyright through pip instead of Mason and see if anything changes.

[martin-scheele]

The pip version still doesn't have logs but now go to definition works for the Python builtins in the aforementioned problem file. As far as I can tell that's the only functional difference between them.

[DetachHead]

hmm it sounds like there may be something wrong with the mason's bundled version of basedpyright then. you may want to raise an issue at https://github.com/williamboman/mason.nvim

[martin-scheele]

Yeah, if I have the time I'll try to recreate the problem with a minimal neovim config just so I can rule some things out and there's actually more to go off of.

It's still strange that there aren't any logs though, right? As well as the other missing functionality even when installing via pip. I have to imagine that if that was the case for everyone using basedpyright with neovim that someone would have raised an issue before me.

In any case, thanks for trying to help me with this even though you're not a neovim user. Maybe I'll actually have to learn lua and the inner workings of neovim and come back with something to go off of lol.

[LupusAnay]

Hi! I've encountering similar issue with Neovim on macOS (M1). macOS version: 15.2 python version: 3.13.1 basedpyright version: 1.24.0 based on pyright: 1.1.392

Here's minimal config ~/.config/<nvim-config-name>/init.lua:

require("lspconfig").basedpyright.setup({
	settings = {
		["basedpyright"] = { analysis = { diagnosticMode = "workspace" } },
	},
})

vim.g.mapleader = " "
vim.keymap.set('n', '<leader>la', vim.lsp.buf.code_action, { noremap = true, silent = true })

I use git clone to install nvim-lspconfig

git clone https://github.com/neovim/nvim-lspconfig ~/.config/<nvim-config-name>/pack/nvim/start/nvim-lspconfig

After that, I create a sample project with basedpyright and numpy installed in venv

python3 -m venv .venv
source .venv/bin/activate
which pip #.venv/bin/pip
pip install basedpyright numpy
NVIM_APPNAME=<nvim-config-name> nvim main.py

Contents of the main.py

#from numpy import zeros
x = zeros(2)
print(x)

Expected behavior when I trigger a completion by pressing <leader>la: A list shown with a suggestion to import zeros from numpy

Actual behavior: "No code actions available" is printed

The package is resolved correctly if I remove the comment from the first line, and the server even suggests to import other names from the same package. It also seems to be working correctly with stdlib packages.

What is the similar with the described issue - I also cannot access any logs, the output of :LspLog is totally empty.

Although, maybe I misunderstood the features of the server, and import suggestions aren't designed to work in this case, but missing logs are still strange.

[DetachHead]

The package is resolved correctly if I remove the comment from the first line, and the server even suggests to import other names from the same package.

so if you uncomment the import, then comment it out again, the import suggestions work? if so, that sounds like the same issue as #545

[LupusAnay]

The package is resolved correctly if I remove the comment from the first line, and the server even suggests to import other names from the same package.

so if you uncomment the import, then comment it out again, the import suggestions work? if so, that sounds like the same issue as #545

Hi! Sorry for the late response. Somehow, I missed the issue you mentioned.

To answer your question - no, if I uncomment the import and comment it out again - suggestions don't work. The behavior is correct only if there are already symbols imported from the module in question. It doesn't even work for the child modules. For example, with

from numpy import array

the code action for adding import from numpy import zeros works

But it doesn't work for the numpy.typing.ArrayLike. If I do import something from numpy.typing - then it works. If I comment the imports again, suggestions become unavailable.

Also, I've reproduced the same behavior with Neovim on Linux (arch)

[DetachHead]

Hi! Sorry for the late response. Somehow, I missed the issue you mentioned.

To answer your question - no, if I uncomment the import and comment it out again - suggestions don't work. The behavior is correct only if there are already symbols imported from the module in question.

i see, same thing happens to me, seems like it only works if you import something else from the module then trigger the import suggestions. only then does it seem to work when commenting out the import entirely. i still think this the same underlying issue as #545

It doesn't even work for the child modules. For example, with

from numpy import array

the code action for adding import from numpy import zeros works

But it doesn't work for the numpy.typing.ArrayLike. If I do import something from numpy.typing - then it works. If I comment the imports again, suggestions become unavailable.

do you mean the import suggestion doesn't work when you type numpy.typing.ArrayLike? if so, that sounds like the same issue as #992

both of these seem unrelated to the original issue though, especially since i was able to reproduce these in vscode and @martin-scheele said the issue only occurs in neovim

[DetachHead]

closing as this is likely an issue with the mason bundled version of basedpyright, as mentioned in https://github.com/DetachHead/basedpyright/issues/684#issuecomment-2395294915

if it turns out i'm wrong, let me know and we can re-open