Add strict_override_decorator option (PEP 698)

[cdce8p]

Add the strict mode for PEP 698.

Closes: #14072

[emmatyping]

One minor wording suggestion but I think this looks good otherwise!

[cdce8p]

Pushed a new update. The error message now includes the base class name. Similar to pyright.
The PR would be ready now.

[JukkaL]

Thanks for the PR! Looks good overall, some suggestions below. This is an important feature to have in mypy.

[JukkaL]

Test using override imported from typing_extensions on an older Python version?

[cdce8p]

I rather not do that. Since none of our test fixtures use @override, we inadvertently get errors for those as well. That's also why I added a separate fixture for these test cases with just enough definitions and no accidental overrides. I would have to do the same just for the typing_extensions fixture.

There is also a test case for an unused @override already. As this PR doesn't change the decorator parsing, it probably fine to skip it.

mypy/test-data/unit/check-functions.test

Lines 2937 to 2947 in 67cc059

	[case explicitOverrideFromExtensions]
	from typing_extensions import override
	class A:
	def f(self, x: int) -> str: pass
	class B(A):
	@override
	def f2(self, x: int) -> str: pass # E: Method "f2" is marked as an override, but no base method was found with this name
	[typing fixtures/typing-full.pyi]
	[builtins fixtures/tuple.pyi]

[cdce8p]

Thanks for the review @JukkaL! Using a new error code instead of a cmd line option does make sense. The change was fairly strait forward. With that I also updated the documentation and added a whole new section in error_code_list2.rst.

For now I used explicit-override as error code. Happy to change that if we can come up with something better though.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[JukkaL]

Thanks for the updates, looks good!