Refactor error messages into a single file

[tushar-deepsource]

Description

This PR moves all errors thrown by mypy into the already-exsting message_registry.py, while also wrapping every error message into an ErrorMessage class.

This is an effort to be able to add unique codes to every error that mypy throws, to resolve #10843.

Changes

• Almost all of mypy's error messages are either static strings, or are templates which are filled using str.format. So, instead of having them scattered around all of the files, this puts every single error raised into message_registry.py.
• Instead of passing a separate msg string and code value into every fail() method call, now error messages being raised are ErrorMessage objects, which puts the error message and error code together.

Progress

This tracks how many files have been migrated from strings to the central ErrorMessage approach.

• Migrate checkers.py
• Migrate other checker files
• Migrate typeanal.py
• Migrate smaller semantic analyzers
• Migrate enums, typeddict and namedtuple analyzers
• Migrate checkerstrformat.py
• Migrate messages.py
• Migrate semanal.py
• Fix abstract classes in plugins.py
• Migrate plugins

There are also a few instances of ErrorMessage objects being created outside message_registry.py for supporting dynamic behaviour. Most of those can be removed as well, which is work in progress.

Future plans

I would also like to properly categorize all of the error messages, and then eventually assign unique identifiers: either numeric (eg. E0163), or readable (eg. unreachable-right-operand) to every single message. This would allow much easier identification of error messages by people, or by other tools.

Suggestions

I'd like to know about any suggestions, changes you'd want to make, or things I have overlooked. Do let me know! I'd be happy to make changes accordingly.

[TH3CHARLie]

Thanks for working on this. This really is a nice refactoring though its own complexity may be too much to pack into a single PR. I feel it's completely OK to open separate ones to do the refactoring.

[tushar-deepsource]

@TH3CHARLie Okay, how do I go about breaking this down. Maybe break it into checkers/semanal/messages and so on? each with 300 or so lines changed?

[TH3CHARLie]

That would be a decent approach, you can use your bullet list to break up the PR. I think that provides a very nice plan.

[tushar-deepsource]

you can use your bullet list to break up the PR

@TH3CHARLie Alright, I'll do that.

The only issue seems to be that mypyc doesn't compile with the ErrorMessage class I introduced. Something about not being able to determine types. Every other test passes. Some bug?

[emmatyping]

This change will also affect several plugins I expect, so if you want to go ahead with a split up version of this, we should notify plugin maintainers in #6617

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

core (https://github.com/home-assistant/core.git)
+ homeassistant/components/gios/__init__.py:33: error: unused "type: ignore" comment

pydantic (https://github.com/samuelcolvin/pydantic.git)
+ pydantic/mypy.py:567: error: Unexpected keyword argument "code" for "fail" of "CheckerPluginInterface"  [call-arg]
+ pydantic/mypy.py:567: error: Argument 1 to "fail" of "CheckerPluginInterface" has incompatible type "str"; expected "ErrorMessage"  [arg-type]
+ pydantic/mypy.py:571: error: Unexpected keyword argument "code" for "fail" of "SemanticAnalyzerPluginInterface"  [call-arg]
+ pydantic/mypy.py:571: error: Argument 1 to "fail" of "SemanticAnalyzerPluginInterface" has incompatible type "str"; expected "ErrorMessage"  [arg-type]
+ pydantic/mypy.py:575: error: Unexpected keyword argument "code" for "fail" of "SemanticAnalyzerPluginInterface"  [call-arg]
+ pydantic/mypy.py:575: error: Argument 1 to "fail" of "SemanticAnalyzerPluginInterface" has incompatible type "str"; expected "ErrorMessage"  [arg-type]
+ pydantic/mypy.py:583: error: Unexpected keyword argument "code" for "fail" of "CheckerPluginInterface"  [call-arg]
+ pydantic/mypy.py:583: error: Argument 1 to "fail" of "CheckerPluginInterface" has incompatible type "str"; expected "ErrorMessage"  [arg-type]
+ pydantic/mypy.py:587: error: Unexpected keyword argument "code" for "fail" of "SemanticAnalyzerPluginInterface"  [call-arg]
+ pydantic/mypy.py:587: error: Argument 1 to "fail" of "SemanticAnalyzerPluginInterface" has incompatible type "str"; expected "ErrorMessage"  [arg-type]

pytest (https://github.com/pytest-dev/pytest.git)
+ src/_pytest/python_api.py:719: error: Subclass of "Iterable[Any]", "Sized", and "bytes" cannot exist: would have inconsistent method resolution order  [misc]
+ src/_pytest/python_api.py:719: error: Subclass of "Iterable[Any]", "Sized", and "str" cannot exist: would have inconsistent method resolution order  [misc]
+ src/_pytest/cacheprovider.py:143: note: (Skipping most remaining errors due to unresolved imports or missing stubs; fix these first)
- src/_pytest/cacheprovider.py:143: error: Returning Any from function declared to return "Path"  [no-any-return]
- src/_pytest/cacheprovider.py:153: error: Returning Any from function declared to return "Path"  [no-any-return]
- testing/test_tmpdir.py:52: note: (Skipping most remaining errors due to unresolved imports or missing stubs; fix these first)

[JukkaL]

I'm not sure if this is the right direction (see #10843 (comment)). This could break backward compatibility or regress usability of # type: ignore[...] comments, in particular.

[tushar-deepsource]

@JukkaL This PR at least, i believe doesn't change any usability at all.

Regarding the introduction if fine-grained error codes, it can be implemented along with the already existing error codes, see #10843 (comment) for an example. I'd be happy to clarify if it's unclear.