microsoft / pylance-release

Documentation and issues for Pylance
Creative Commons Attribution 4.0 International
1.7k stars 768 forks source link

Don't show errors in stdlib files #6453

Open mjbvz opened 1 week ago

mjbvz commented 1 week ago
  1. Turn on analysis
  2. Run go to definition on join from os.path

Bug My problem count explodes:

Image

I wouldn't expect analysis to kick in for files from the standard library like this

rchiodo commented 1 week ago

I would hazard a guess that you have a pyproject.toml or a pyrightconfig.json? The errors are likely a result of this: https://github.com/microsoft/pylance-release/wiki/Settings.json-overridden-by-Pyrightconfig.json-or-Pyproject.toml

It's forcing your typecheckingmode to default to 'basic'

mjbvz commented 1 week ago

I'm pretty sure I just turned on type checking from the language status menu. I don't see those files in my project

Image

rchiodo commented 1 week ago

That's expected behavior then. typeCheckingMode applies to all open files, regardless of if they're under a workspace folder or not.

What you're asking for is typechecking only on 1st party source and not 3rd party source it seems like? Seems reasonable to me. Why would anybody care to type check code that isn't their own?

rchiodo commented 1 week ago

One way to workaround this is to add a glob to the 'ignore' setting:

"python.analysis.ignore": ["${workspaceFolder}/venv/**/*"]
rchiodo commented 1 week ago

Maybe we should add all of the site-packages folders to the default ignore list?

heejaechang commented 1 week ago

we show errors from any file opened in vscode. if your go to def opened a file, we will show errors on that file as long as it stays as open. once you close that file, they will go away. and that behavior is by design to support orphan files opened in editor along with folder

you could request enhancement request though. and we see how many upvote we get.

mjbvz commented 1 week ago

Feels like this scenario is common enough that ignoring the standard library would be a reasonable default. When would you want these errors to show up?

heejaechang commented 1 day ago

standard library typeshed authors? it would be nice to have a way to categorize problems in UI. so less important errors can group differently than other more important errors.

mjbvz commented 1 day ago

standard library typeshed authors?

Having an option (with no errors reported by default) seems reasonable for the majority of users

heejaechang commented 1 day ago

we could add an option for it, but usually user doesn't leave stdlib file open for long time? they usually either open it to see some definition/signature and close it. what is the scenario where you leave them open for long time?

mjbvz commented 1 day ago

Yes that's exactly the problem I ran into:

  1. Run go to def on stdlib symbol to quickly browse the code
  2. File opens and I am flooded with 100+ errors
  3. The errors do go away after I close the file but it's distracting to suddenly have that many errors appear and also distracting to see all the red lines highlighted in the stdlib file
Ravencentric commented 13 hours ago

I would love to see everything in stdlib/venv get excluded. It's just pointless distraction.