Support both warnings and errors

[JukkaL]

We should have both errors (for things that clearly violate the type system) and warnings (for style issues and things that are suspicious but not necessarily problems). There should be a command line option for enabling/disabling warnings. Not sure whether warnings should be on by default -- probably yes.

[jhance]

Things an ideal warning system does:

• Ability to turn warnings (specific types) into errors.
• Color differentiation (I prefer three colors, one for warnings, one for warnings that are set to be errors, and one for actual errors)
• Ability to disable specific warnings/all warnings

[JukkaL]

All of those could be pretty nice. Once somebody starts working on this, we could have separate issues for all of the enhancements so that we can discuss different designs.

We should also think about various things that could generate warnings. Redundant casts (#958) is one example. Other possible things to warn about that come to mind:

• Local variable is assigned a value but this is never read (linters already catch this, though).
• Missing return statement on some code path in a function that returns a value (alternatively, this could be an error with strict None checking).
• Imported name is never used in a module.
• Internal module-level definition (prefixed with _ or not in __all__) is never used in a module.
• Dead code that can't ever be reached (e.g., in a block after raise).
• Statement with a literal expression that is not a docstring (has no effect).
• Variable could be uninitialized as it doesn't get a value on all code paths.
• Forgot to call base class __init__ in an __init__ method.
• [], {} or set() as default argument value (this can be okay, but it often is an error).

[rwbarton]

• isinstance checks that will always return True or always return False probably indicate a mistake (in the latter case we have to assume no multiple inheritance).

[oscarbenjamin]

As far as I can tell most of the things referred to above are implemented now. The specific feature that I would like which is not implemented is:

• Ability to turn warnings (specific types) into errors.

For example I see warnings such as:

$ cat t.py 
def f():
    x: int = 1
$ mypy t.py 
t.py:2: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs  [annotation-unchecked]
Success: no issues found in 1 source file
$ echo $?  # exit code
0

I can silence the warning but I can't find any option to make it an error instead.