The mypy-primer output here is unexpected, right? The new error is off by default so it shouldn't trigger on existing code.

The mypy-primer output here is unexpected, right? The new error is off by default so it shouldn't trigger on existing code.

Indeed, I'm not sure what's causing that. When I run mypy from this branch by default I'm not seeing the option take effect.

Separately, I have noticed that if I run mypy from this branch initially without the new option and then run it with the new option the errors aren't found when they should be:

$ cat foo.py
foo  # type: ignore
$ mypy foo.py
Success: no issues found in 1 source file
$ mypy foo.py --disallow-ignore-without-code
Success: no issues found in 1 source file

Changing the test file seems to get the error to show up, so I'm wondering if there's some caching that I've missed?

re: primer, I think you might have automatically included it in --strict (see the strict_group stuff)

I think you might have automatically included it in --strict (see the strict_group stuff)

Ahhh, yeah. That was actually intentional and I'd forgotten I'd done it. I'm not sure whether this qualifies for --strict (or how that gets decided), but it's something I'd be interested in including in the strict mode.

Perhaps it would be better to introduce this flag first and then later move it into --strict?
(If --warn-unused-ignores isn't in --strict then adding it at the same time might also make sense)

Yeah, I think we should introduce this first and only later consider moving it into --strict, since this has a pretty large impact on users of --strict. I'd also want to make sure that the error codes mypy provides for common errors are useful before doing so to reduce future breakage; I think currently we have a lot of error code "misc".

My approximate mental model for --strict is "you shouldn't ever have type errors without an explicit circumvention somewhere". Or "this is what the default behaviour of mypy should be if all Python were typed".
If today was the first day of mypy I'd be more willing to include it; in our current world I lean towards avoiding breaking unsuspecting users since it's just an adjustment of something that's already explicitly opting in to type unsafety.

--warn-unused-ignores is already part of --strict, but --show-error-codes is not (but should be, if this is incorporated into --strict). Speaking of which, if possible, it would be really nice to show which error code(s) to add in your error message.

Yeah, I think we should introduce this first and only later consider moving it into --strict, since this has a pretty large impact on users of --strict. I'd also want to make sure that the error codes mypy provides for common errors are useful before doing so to reduce future breakage; I think currently we have a lot of error code "misc".

Ah, fair. I've personally found that while a lot of things were misc, most things now aren't (:+1: to whoever was pushing that a while back). I can definitely see the desire to get misc even lower before requiring codes though 👍

... if possible, it would be really nice to show which error code(s) to add in your error message.

Good point, I think it should be easy to add that.

Separately, I have noticed that if I run mypy from this branch initially without the new option and then run it with the new option the errors aren't found when they should be

I believe I've fixed this in c811aa7.

I think this would be better enabled via --enable-error-code <something>, instead of adding a new command-line option. The motivation is to avoid continuously increasing the size and complexity of the command-line interface.

(Some of the existing flags would work better using --enable-error-code, but they were added before --enable-error-code was available and maintaining backward compatibility is useful.)

@JukkaL thanks, I've changed over to this being an error code (still disabled by default).

I can handle getting this through, since Jukka and Shantanu already commented here without objections to the overall idea. If you fix the conflict, I'll do another round of review, then merge if everything looks good.

Thanks! I'll fix that conflict now 👍

Looks like a test needs to be updated.

Just curious, what happens if you have a # type: ignore[pyright] or some other code that doesn't exist?

Just curious, what happens if you have a # type: ignore[pyright] or some other code that doesn't exist?

Currently nothing specific from this new error code. --warn-unused-ignores does pick it up though.

One thing I have spotted here is that it's now possible to have several errors from the same problem, as shown by the testErrorCodeMissingDoesntTrampleUnusedIgnoresWarning test:

# flags: --enable-error-code ignore-without-code --warn-unused-ignores
z # type: ignore[ignore-without-code]

generates three messages:

• Error: Unused "type: ignore" comment
• Error: Name "z" is not defined [name-defined]
• Note: Error code "name-defined" not covered by "type: ignore" comment

While I'm not sure if this is something created by this PR, is this something we want to address here?

While I'm not sure if this is something created by this PR, is this something we want to address here?

I'd rather cover that in a separate PR. Maybe we should suppress the Unused "type: ignore" comment error?

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Just want to express my gratitude to @PeterJCLaw for writing and @JelleZijlstra for reviewing this PR. We have been waiting patiently for this function, nice to see it got merged 🎉 Thanks guys!