Error code for subclassing final

[Avasam]

Is your feature request related to a problem? Please describe.
In typeshed, there's a few instances of having to subclass a final type. Since pyright does not provide an error code for that specific error, we have to blanket # pyright: ignore.

Describe the solution you'd like
An error code for subclassing final classes.

[erictraut]

Pyright doesn't support error codes. It supports diagnostic checks which have names like reportUnusedVariable, etc. I don't think it makes sense to create a new diagnostic check specifically for subclassing of final types. A @final class decorator has a very specific and well-defined meaning, and I would recommend against ever attempting to subclass a final class because it will break many other assumptions and checks in a static type checker.

[AlexWaygood]

For additional context: the reason why we very occasionally subclass @final classes in typeshed is to account for situations like this, where classes cannot be subclassed in pure Python but nonetheless have real, existing subclasses in the stdlib:

>>> dict_keys = type({}.keys())
>>> dict_keys
<class 'dict_keys'>
>>> class Foo(dict_keys): ...
... 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: type 'dict_keys' is not an acceptable base type
>>> from collections import OrderedDict
>>> type(OrderedDict().keys())
<class 'odict_keys'>
>>> _.__mro__
(<class 'odict_keys'>, <class 'dict_keys'>, <class 'object'>)

When writing a stub for dict_keys, the only logical thing to do is to mark it with @final in the stub, since it cannot be subclassed in pure Python. But that means we have to pyright: ignore our stub for collections.odict_keys, since the odict_keys class subclasses a @final class.

I appreciate that this is a pretty unusual use case, however, so it's fine to leave this as a wontfix if you don't think it's worth it.