Closed thesadru closed 1 year ago
rchiodo
commented
1 year ago I think what you're saying is that errors show that are out of date?
The surest way to get pylance to reload is to run Developer: Reload Window but that might be too big of a hammer.
Some other ways are to:
However, pylance shouldn't be showing out of date diagnostics.
Can you share your settings.json? Or perhaps some more steps that cause a repro?
erictraut
commented
1 year ago This could be indicative of an error that is reported only when certain evaluation ordering occurs. Pyright uses just-in-time (lazy) evaluation, so the evaluation order of expressions can vary depending on the order in which you open files, edit files, hover over identifiers, etc. This makes the evaluation order somewhat non-deterministic (or at least, difficult to predict). We have occasionally had bugs in the type evaluator that causes an error to be reported for some orderings and not for others. Obviously, that should never happen if things are working correctly. These tend to be very difficult bugs to repro because they're intermittent. Does that sound like what you're seeing? If so, we'll need to put our heads together to come up with a way to repro the problem.
erictraut
commented
1 year ago Is it always the same error message? Or perhaps the error is on a particular type of expression (a list or tuple, for example)? Any clues or patterns that you can discern may be helpful.
thesadru
commented
1 year ago Can you share your settings.json? Or perhaps some more steps that cause a repro?
There are no settings.json in that example. As far as I know, this should be a general recurring issue as I have been experiencing it on various machines. It's always sudden and not really predictable for me.
I think what you're saying is that errors show that are out of date?
The diagnostics cannot be out of date considering this also happens to code in files that have not been touched during that session.
We have occasionally had bugs in the type evaluator that causes an error to be reported for some orderings and not for others. [...] Does that sound like what you're seeing?
I have unfortunately never tried to check for different orderings considering the errors go away if the file is attempted to be edited.
Is it always the same error message? Or perhaps the error is on a particular type of expression (a list or tuple, for example)? Any clues or patterns that you can discern may be helpful.
In previous versions this issue was very commonly related to imports, these days it's however for seemingly random tokens - unknown variables, attributes, and members, unused variables, etc.
erictraut
commented
1 year ago Do you set python.analysis.diagnosticMode to "workspace", by any chance? Or do you have it configured to report diagnostics for "openFilesOnly"? If it's the latter (which is the default setting), then I presume that the "files that have not been touched" are open in your editor at the time the errors appear?
thesadru
commented
1 year ago I have it set on workspace for my global user settings, yes. It can happen in any file that can be analyzed by pyright based on pyproject.toml
erictraut
commented
1 year ago OK, that's a good hint. Very few pylance users use "workspace" diagnostic mode, which would explain why we haven't received other reports of this problem. I'll see if I can find a repro.
Do you happen to remember when this started to occur? Was there a point in time when you remember it not occurring? I'm just trying to pin down whether it was a regression or something that has always existed.
thesadru
commented
1 year ago I have a feeling that the problems with imports go back more than a year but I have no idea how long it's happening for other diagnostics. A few months at least that's for sure. At some point, I kinda became accustomed to it, unfortunately.
erictraut
commented
1 year ago OK, thanks for the hints. I just tried loading a big project (250K LOC) and spent some time opening editing and closing files to force reanalysis of portions of the project. I didn't encounter anything like what you're seeing. Like I said, these can be really elusive, so it may take a while to gather enough clues.
One thought is that this might be occurring after we hit our internal memory limit and flush the in-memory caches to make more space. When we do this, we log it in the Output. If/when you see this happen again, please switch tot he Output window for pylance ("Python Language Server") and see if there's any indication of this.
And if you encounter any other clues or detect any other patterns, please let us know.
thesadru
commented
1 year ago Correct me if I'm wrong, but if this is really an actual issue it should probably stay open no?
debonte
commented
1 year ago Sorry, I guess we misinterpreted Eric's last message. I'll reopen. Let us know if you find any other clues.
maflAT
commented
1 year ago I might have another clue.
I noticed the same sporadic non-sensical errors. Also using workspace diagnostic mode.
The project that showed those errors also has some import cycles. (Not present at runtime, only when type checking.)
I figured maybe that might have something to do with it. Because as @thesadru mentioned, it started with unknown import symbols.
Sadly i can't publish the code here and i was not able to reproduce it with a minimal example.
rchiodo
commented
1 year ago I'm going to close this until we can get a repro. Without that there's not a way for us to act on it.
thesadru
commented
1 year ago It happened again at some point.
triggered while my CI was running, might be caused by that
rchiodo
commented
1 year ago @thesadru What are the errors like? If there's a bunch of import errors, might be we're losing the import paths somehow.
thesadru
commented
1 year ago Not import errors, just random ones like variables not being used or attributes not existing and such.
rchiodo
commented
1 year ago Is the CI updating files in the background? It looks like we're receiving random file change events (changes not issued by the editor). That might be messing stuff up if the file change events are making our internal view of a file be incorrect.
thesadru
commented
1 year ago Yes it is, I think it's most likely black/isort doing that.
For months pylance had a tendency to just randomly show nonsensical errors that do not show up when running pyright in the cli. This has been partially fixed several times and these days a simple file change can make the errors go away in sometimes even several files.
Is there however a way to make pylance do a quick reload of all the files targeted by pyright to make sure the errors don't have to be updated manually?
Attributes that definitely do exist:
there are always several errors across multiple files (becomes 0 after any edit):