Document exit codes for mypy and dmypy

[ilevkivskyi]

See #5982. The rough idea is to exit with:

• 0, if no type errors
• 1, if there are some type errors
• 2, in case of a crash, bad arguments, and other non-standard conditions

[adaszko]

Hi. Should I raise a separate issue for a non-conformity with the above guidelines?

$ pipenv run mypy .
. is not a valid Python package name
$ echo $?
1

I believe that should be a 2.

[gvanrossum]

Thanks -- in general that would be recommended, but in this case it's so simple that I'll just prepare a fix.

[rolandcrosby-check]

Hi, I noticed that adding a Mypy reveal_type call in code that otherwise typechecks correctly causes Mypy to exit with code 1 (it also causes Mypy to not print a "success: no issues found" or "found X errors" message). I can't find any reference to this behavior in Mypy documentation and can't tell if this is expected or if there's a way to work around it.

If Mypy exit codes ever get documented as discussed in this issue, could we ensure that the documentation also addresses the expected impact of reveal_type on the exit code?

[intgr]

1, if there are some type errors
2, in case of a crash, bad arguments, and other non-standard conditions

That's bad. Bugs in mypy plugins can also make it crash with status 1, e.g. typeddjango/django-stubs#760 crashes with 1.

It's the default exit code when Python exits with an unhandled exception, so it's not a good choice for applications to distinguish between "there were type errors" and "mypy crashed"

I was relying on the exit code in the PyCharm plugin, but since it's unreliable, seems like I need to implement some more complicated heuristic.