'Unnecessary "# type: ignore" comment' error can not be silenced

[jakkdl]

Is your feature request related to a problem? Please describe.
I'm writing a typetest testing file for a project to check TypeVarTuple behaviour, and since that's not yet fully implemented in mypy it incorrectly raises some errors. Ideally there would be a # mypy: ignore (I tried searching their issue tracker for why this is not supported, but failed to come up with good search terms), and using # type: ignore gives Unnecessary "# type ignore" in pyright. I hoped to be able to silence that with # pyright: ignore[unnecessaryTypeIgnoreComment] or even a naked # pyright: ignore - but neither works.

I really want reportUnnecessaryTypeIgnoreComent enabled, as that is the only way to check that I'm getting the expected errors when doing incorrect calls - but currently seems like the only way to achieve what I want is to have two separate files for mypy and pyright.

minimal repro

a = 7  # type: ignore  # pyright: ignore
a = 7  # type: ignore  # pyright: ignore[unnecessaryTypeIgnoreComment]

output:

$ pyright foo.py 
/tmp/foo.py
  /tmp/foo.py:1:10 - error: Unnecessary "# type: ignore" comment
  /tmp/foo.py:1:26 - error: Unnecessary "# pyright: ignore" comment
  /tmp/foo.py:1:26 - error: Unnecessary "# pyright: ignore" comment
  /tmp/foo.py:2:42 - error: Unnecessary "# pyright: ignore" rule: "unnecessaryTypeIgnoreComment"
4 errors, 0 warnings, 0 informations 

Describe the solution you’d like
No errors to be raised, at least for the second line. The first line runs into trouble where the self-referential nature might mean that a lone # pyright: ignore would never be marked as unnecessary, as it's ignoring itself.

I imagine unnecessaryTypeIgnore is specially handled, as errors printed do not have any "group" associated with them, but would be great if this was doable.

[erictraut]

As you surmised, the reportUnnecessaryTypeIgnore is handled in a special manner, in a different pass from all other type checks, so doing what you propose here isn't really feasible.

It sounds like you're jumping through hoops to work around limitations in mypy. Out of curiosity, why do you want to use both pyright and mypy on the same code base? You can avoid these issues if you stick to one type checker or another.

As you said, the right solution here is for mypy to add a mypy-specific way to suppress errors. There is an open issue in the mypy issue tracker for this feature. Please consider upvoting it.

[jakkdl]

I don't want to run both on the full code base, just run both in tests to make sure that the trio library can be type-checked against with both type checkers a la https://typing.readthedocs.io/en/latest/source/quality.html - and would be nice not to have to duplicate the testing code or similar.

Thanks for linking the issue! Will vote on it.