Omit declaring .new constructors for abstract classes in generated RBI files

[olivier-thatch]

Following this recent change in Sorbet (released in 0.5.10810), RBI files generated by Tapioca for third-party gems went from declaring class constructors like this:

class Foo
  # source://sorbet-runtime/0.5.10795/lib/types/private/abstract/declare.rb#37
  def initialize(*args, **_arg1, &blk); end
end

to being declared like this:

class Foo
  class << self
    # source://sorbet-runtime/0.5.10838/lib/types/private/abstract/declare.rb#37
    def new(*args, **_arg1, &blk); end
  end
end

This causes Sorbet to type the return value of Foo.new as T.untyped: https://sorbet.run/#%23%20typed%3A%20true%0A%0Aclass%20Foo%0A%20%20%23%20def%20initialize%28*args%2C%20**_arg1%2C%20%26blk%29%3B%20end%0A%0A%20%20class%20%3C%3C%20self%0A%20%20%20%20def%20new%28*args%2C%20**_arg1%2C%20%26blk%29%3B%20end%0A%20%20end%0Aend%0A%0Afoo%20%3D%20Foo.new%20%0AT.reveal_type%28foo%29%20%23%20revealed%20type%3A%20T.untyped%0A

I asked about this in the Sorbet Discord and @jez (author of the Sorbet PR that caused this change) said that ideally, Tapioca should not generate a signature at all for constructors in abstract classes:

IMO we should hide these definitions in tapioca-generated RBI files. i’d suggest making a feature request against tapioca
Either the generated RBI needs to have a sig that declares the return type being T.attached_class, or better they need to omit declaring a signature for new so that Sorbet’s intrinsic new -> initialize forwarding works

[jez]

To be clear: not all constructors, just the ones in abstract classes