Expose config to filter diagnostics by pattern-matching

[micimize]

More granular control in some form is desirable to users in many scenarios (i.e #497, microsoft/pyright#3220, microsoft/pyright#3192), but pyright won't be getting more granular per-rule diagnostic controls anytime soon (microsoft/pyright#3221).

Thus, I think a reasonable middle ground would be to add a configuration for ignoring errors based on regex patterns (microsoft/pyright#3221 (comment)). This would allow users to explicitly silence the errors they don't (currently) care about, without disabling whole swaths of the typechecker, while not requiring a detailed rule taxonomy from the developers, and would actually also be even more granular than more granular diagnostics anyways.

I opened here as I think it makes more sense to implement in the interface layer, as it seems more appropriate to treat it like adding | grep -v "$IGNORE_PATTERNS" to the end of a cli call than a core API, but that may make less sense given that vscode-pyright exists.

[debonte]

If we were going to implement this, I would expect it to happen in Pyright.

@erictraut

[erictraut]

I agree that if we were to implement this, it should be in pyright not in pylance. It's a core type checking feature, not an LSP feature. That said, I don't think this should be implemented, at least not as specified above. Filtering by diagnostic text is fragile because we regularly change diagnostic messages for improved clarity and updated type syntax.

Pyright already offers close to 50 separate diagnostic control knobs, which provide significant granularity of control.

I recommend that we keep this feature request open within the pylance issue tracker to see if we get signal from other users that this is a broader problem. For anyone who would like to add to the discussion, my first question will be "what specific diagnostic messages do you think should be split out into separate diagnostic rules and why?".

[micimize]

@erictraut I already linked to several threads referencing specific rules. Having lengthy debates about every single scenario is not a reasonable ask. There's already a 30-comment-deep debate about reportGeneralTypeIssues being overly broad in #497 from 2020, which is similar to other issues I've had.

Adding a more precise rule code taxonomy would solve most of this problem more robustly, but has already been rejected. But anyways, it wouldn't be able to account for scenarios like microsoft/pyright#3192 where there is a library or scenario-specific behavior that one might want to silence.

I'd rather have to maintain a list of fragile regexs than only use mypy. There could be a big warning in the docs about it not being reliable or experimental or w/e.

[micimize]

One last thing maybe worth mentioning about the surrounding context - if it was possible to run vscode-pyright next to pylance, or something along those lines, then I would consider forking and adding/experimenting with some of the features that have been discussed, but that doesn't seem possible at the moment.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.