can't get diagnosticSeverityOverrides to work

[zzzeek]

running code-1.64.2-1644445844.el7.x86_64.rpm on fedora.

I've tested to see if "user" settings are getting in the way, and they're not, there's nothing activated in "user" settings. In "workspace" settings, we have at the end:

{
...
    "python.analysis.typeCheckingMode": "strict",
    "python.analysis.diagnosticSeverityOverrides": {
        "reportPrivateUsage": "none"
    },
}

this settings file is definitely taking effect, because if I set "strict" above to "none" in that settings.json file, code linting turns off as expected. however, when i set back to "strict" above, red lines come back, including those that claim they are "reportPrivateUsage". This seems to be the case for other settings as well. see screenshot

I tried it the other way around too. like maybe we start with type checking mode "none" or "basic" and add the rules in. that also doesn't work. setting to "info" etc., no effect. So far ive not seen evidence of this setting doing anything other than I get the dropdown for it with all the values when im editing it.

[erictraut]

Do you have a pyrightconfig.json file in your project? If so, it's overriding the diagnosticSeverityOverrides. This bug has apparently been in place for more than a year, but it was discovered and reported by a pyright user last week here. I've introduced a fix, and it will be included in this week's pylance release.

[zzzeek]

oh, it reads my pyright settings? turns out that's great because I'd much prefer to have this in my pyproject.toml which apparently is supported !

what threw me off is that pyright at the CLI doesn't seem to report this error at all; per https://github.com/microsoft/pyright/blob/main/docs/configuration.md it's set to default at "none", but if I positively put it there in my pyproject.toml settings, then pylance picks it up.

im good on this end, thanks!

[erictraut]

Yeah, I think most people use either a pyrightconfig.json (or pyproject.toml) or a VS Code settings file, but very few combine the two. That would explain why this bug went unnoticed for so long.