Handle class attributes used inside concerns

[vinistock]

Motivation

Sorbet is not able to identify class attributes created inside included blocks in concerns, which leads to false positives for method missing.

E.g.:

module Concern
  extend ActiveSupport::Concern

  included do
    class_attribute :title
  end
end

class Article
  include Concern
end

Article.title # => Method missing! (false positive)

Tapioca can find these attributes when we find dynamic inclusion and extension and output the complete RBIs.

Implementation

• Moved the original logic into DynamicMixinCompiler and modified it to keep track of class attributes
• Started generating class attribute related RBIs inside GeneratedClassMethods and GeneratedInstanceMethods
• Re-generated Tapioca's own RBIs

Next steps

This PR will handle gems that create class attribute inside concerns, but applications can also do the same. We can leverage the same logic in a DSL generator to handle that case as well and produce the correct RBIs for concerns.

Tests

See included tests.

[vinistock]

I have bumped the Sorbet requirement, applied the requested changes and made three fixes:

• started invoking super is defined inside re-definition of class_attribute
• added missing instance attribute checks for the empty? method in DynamicMixinCompiler
• started rejecting names that begin with <# in Reflection#name_of, in order to properly ignore anonymous classes

[paracycle]

Looks great, I have a couple of minor comments

[paracycle]

Perfect. Thank you!

[paracycle]

Fixes #250, more generally

[vinistock]

@paracycle I think that in order to fix #250 we could use the same strategy, but we'd need to also patch attr_reader, attr_accessor and attr_writer to keep track of the generated methods. In the current state, we'll only catch class_attribute.

[paracycle]

... but we'd need to also patch attr_reader, attr_accessor and attr_writer to keep track of the generated methods.

I know but that is one usage that I would not want us to support since it is a bad usage of the language. The user should feel the friction in that case and fix their code.

On the other hand, for things like class_attribute there is no other way to declare them properly, so we should support that use case.