Address silent RBS + dynamic class incompatibility

[sambostock]

Context

As per sorbet/sorbet#9153,

Foo = Class.new(Bar)

can't be combined with

# @abstract
# ...or other RBS annotations...
class Foo

and probably won't ever be supported, because the rewriters for each run in the wrong order for it to work.

That's acceptable, but it's silent, which isn't ideal.

Proposal

If it's not going to work, and Sorbet isn't going to catch it and complain, then at least a cop should complain.

Option 1

We could introduce a cop that simply forbids dynamic classes:

Class.new(Bar)
^^^^^^^^^^^^^^ Bad

This cop could be introduced in rubocop proper, and then enabled automatically by rubocop-sorbet on the basis of this incompatibility.

However that may be too heavy handed, as some codebases may have use cases for dynamic classes. Most of the time, those use cases are in tests, so it may be sufficient to simply exclude those.

Option 2

We could introduce a cop that forbids assigning dynamic classes to constants:

Foo = Class.new(Bar)
^^^^^^^^^^^^^^^^^^^^ Bad

Likewise, this cop could be introduced in rubocop proper, and then enabled automatically by rubocop-sorbet on the basis of this incompatibility.

However that may also be too heavy handed, as it's really only a problem if it's also used with RBS signatures.

Option 3

We could introduce a cop that forbids assigning dynamic classes to constants if RBS comments appear in its documentation:

# @abstract
Foo = Class.new(Bar)
^^^^^^^^^^^^^^^^^^^^ Bad

This cop would be specific to rubocop-sorbet and the least reusable, but the most targeted, and allow a very specific error message.

---

Technically everything here also applies to Module.new.

[Morriar]

I like option 3 better. Looks like you do as well: #353?