Rename symbol: No result

[tekumara]

Environment data

• Language Server version: Pylance language server 2020.9.6 (pyright c52b78aa)
• OS and version: macOS
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.9

Expected behaviour

Renaming a function argument renames its usage within the function

Actual behaviour

No result

Logs

XXX

Code Snippet / Additional information

def go(foo: str) -> str:
    return foo

[tekumara]

Have upgraded and am still experiencing this with Pylance language server 2020.9.7 (pyright a0620921)

[erictraut]

Thanks for the bug report.

I'm not able to repro this in either Pylance or Pyright. Do you have any non-default settings enabled that might affect this?

[jethrobarroso]

I'm also experiencing this exact same issue. Going to try this on another os with a fresh install and report back.

Edit:
Tried on another pc with just the two extensions installed, but it works as expected... So reproducing is not that simple it seems.

[jethrobarroso]

Ok so I've discovered something, but I'm not yet sure if this is related to pylance itself.

I'm able to perform a rename in a workspace without a venv. As soon as I create a new venv then I'm unable to rename.
@tekumara Can you confirm this behavior on your side?

[tekumara]

Ah, so in my case it's because I haven't opened a folder yet. This is how I repro:

Open a new VSCode window, and open a single file. Rename symbol will fail in that file. In the same window now open the file's folder. Rename symbol will succeed.

@VladimortZA are you using a pyrightconfig.json? If the include or exclude options are present, check they aren't ignoring the code you are trying to rename. NB: include: "." is assumed if not present.

[erictraut]

Good clue!

Interesting, it looks like this might be a bug in VS Code. The language server isn't receiving an onRenameRequest callback if I open a file and attempt to rename a symbol. If I open a folder and then open a file within it, the rename request is received as expected.

@jakebailey, any thoughts about this?

[jakebailey]

Single file mode has always been a bit shoddy, but it might be an artifact of how the core extension manages the LS connection. A test would be to repeat the same thing with the pyright extension (which doesn't do anything but start the client for all Python requests).

[erictraut]

I already confirmed that the same thing occurs with the Pyright extension, so that would seem to indicate it's a problem with VS Code, not the core Python extension.

[jakebailey]

Very strange. I haven't seen this before (and quick searching the VS Code issues doesn't net anything, but there are literally a hundred thousand issues).

[MiMiMeowMeow]

I have same problem. Must be pretty hard to track down the cause beacuse everybody has different setup...

Python 3.7.7 64-bit. Pylance 2020.12.1, Python 2020.11.371526539

Version: 1.51.1 (user setup)
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-10T23:34:32.027Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19042

For me, it looks like there one file that it misbehaves with. It is the largest file in my project at ~800 lines of code. It seems to work on the smaller files in my project fine. Not sure if it's related to size of the file. There must be something in the large file that making it crap out. I don't really want to post the file publicly.

[MiMiMeowMeow]

Looks like is unrelated to size of the file but the extension of the file. It looks like if the extension is not ".py" you will get this problem. Seen it happen on ".pyw" files and it works fine when renamed to ".py". Should work on all files extentions associated with python. Here are a few:

"files.associations": {
    "*.py*":       "python",
    "*.spec":      "python",
    "SConstruct":  "python",
    "SConscript":  "python"
}

[paulcsimon]

For me this happens when the file is in a project subfolder. In a flat project structure (all files beside each other in the opened folder) the command works as expected. Since all of my projects contain a more or less complex folder structure the bug is quite annoying.

[jakebailey]

We only support python in py and pyi files; any other format isn't supported (and overriding it probably confuses Pylance). I think pyw is the same syntax, so potentially that could be supported, but this is the first time I've seen it in practice.

[MiMiMeowMeow]

pyw extention are for windowed python programs created from wxpython, pyqt, tkinter.
spec files are pyinstaller files that are writen in Python. Scons files are also writen in Python.

[jakebailey]

Just to cross-link it, for extensions that aren't py or pyi, see #739.

[jakebailey]

@MiMiMeowMeow #739 should be fixed in the next release; I don't know if I can close this issue though as the original issue was not file extension related.

[paulcsimon]

No, under no circumstances can this be closed. The original issue hasn't been fixed! #739 is completely unrelated to #441.

[steevelaquitaine]

What solved it for me was to:

1. Open Folder - Select my project folder ...
2. Make sure every single subfolders had an __init__.py
3. Make sure Pylance does not complain about anything under VSCODE "PROBLEMS" tab (Ctrl + J for access)
4. Then selecting the variable - right click - rename symbol - I rename it - Enter.
   ... and it worked.

[majidhas]

For me, the problem was Pylance itself....for temporary solving, you can change the "python.languageServer" in setting json file from "Pylance" to "Microsoft" and then it works with Microsoft.

[jakebailey]

@majidhas if you had a way to reproduce this, that'd be much appreciated. We'd like to fix it here and not have people resort to switching to the old language server.

[zixuzhuang]

I meet this issue, too. But when I try to rename this symbol again, it worked. I don't know why.

[edmond-irani]

I meet this issue, too. But when I try to rename this symbol again, it worked. I don't know why.

I am experiencing the same thing. Sometimes does not work on the first shot, but worked in the second time.
OS: Ubuntu 18.04, VS Code 1.54.3

[jakebailey]

The fact that it fails the first time but succeeds the second time is interesting. I see this with other calls as well, like when I reproduced #227 (which is go-to-def, not rename). I'm wondering if this is all some common issue.

[K4ndo]

I experience the very same issue. Whenever im trying to rename or go-to-def for the first time in a file it does not work. Repeating either command is working just fine though.

[AG-LC]

The fact that it fails the first time but succeeds the second time is interesting. I see this with other calls as well, like when I reproduced #227 (which is go-to-def, not rename). I'm wondering if this is all some common issue.

I have both issues: go-to-def and rename work on the second try only (the first yields "no results"). After doing that in one file, it seems to keep working in this file, but the other open ones still have the issue.

This is VSCode 1.54.3 (system setup) on Windows 10, in a venv.

[erictraut]

This is related to issue #1069. As I mentioned in that thread, my investigation leads me to think this is a bug in the core Python extension.

[jakebailey]

See microsoft/vscode-python#15727; this is a bug in the core extension and we'll fix it there.

[jakebailey]

Just to show the original issue working:

I'll close this (and the numerous other issues the bug caused) when the core extension's point release is done.

Note that the bug I introduced into the core extension was only added earlier this month. It's possible the original issue wasn't fixed but having tested it I believe it to be, so we can reopen it as needed.

[jakebailey]

This is now fixed in the core extension (v2021.3.680753044).

[Hubro]

Should this be fixed in the current stable release? I'm still getting "No result." when trying to rename a simple variable in Python. Should I open a new bug report?

[K4ndo]

The error does not occure in the current stable release. Everthing works perfectly fine for me using VS Code version 1.55.2

[jakebailey]

Yes, please file a new issue. This issue was caused by a client bug that's since been fixed.

[ivan0kurnia]

Hi! In my case this seems to happen when opening a simple file in an untrusted [yet] workspace. It doesn't happen when I open a project (not a single file) in a trusted workspace.

[jakebailey]

The Python extension and Pylance don't (yet) support untrusted workspaces, so no features are going to work as the Python extension doesn't start Pylance.

[DervishD]

I'm sorry to say that this still happens for .pyw files under VSCode 1.60.1 and Pylance v2021.9.1.

As soon as I rename the offending file to .py, the rename symbol function works.

This is happening in a trusted folder.

Is there anything I can do in order to provide more useful information?
Thanks in advance.

[jakebailey]

That would be #1636.

[DervishD]

I checked that, @jakebailey , but apparently Pylance now supports .pyw files, too, per #739, so renaming symbols should work. This is a pure Python file, not some syntax derived from Python, like SageMath.

Also, the file mode is properly set as Python, so I don't get why this should be happening.

Anything wrong on my side that I can check? Thanks a lot for the reply, @jakebailey .

[jakebailey]

I'm not sure what you mean. The linked issue may talk about .sage, but the issue is more generic around anything that's not just a .py or .pyi. The language you have set the file to doesn't change that we are excluding other extensions from our list of source field where refactoring is valid.

[DervishD]

Oh, sorry, my bad then. I assumed that since Pylance supported .pyw files, that included refactoring.

Any possibility of including .pyw as a supported extension for refactoring? I know that extension is very platform specific, as it's only for Windows, and I suppose those files could be renamed and then using some fix they will still work with the proper (non-console) Python for Windows interpreter, but I'm just curious if adding that extension is an easy fix or if it has some deeper implications.

And again, @jakebailey thanks A LOT for your help. I was seeing the whole picture 😃

[jakebailey]

That is precisely what #1636 covers.