Add support for Ruby Structs

[lekemula]

Hi,

This PR adds support for Ruby Struct class definitions both via inheritance and const assignment:

# @param bar [String]
# @param baz [Integer]
class Foo < Struct.new(:bar, :baz, keyword_init: true)
  def foo
  end
end

# @param bar [String]
# @param baz [Integer]
Foo = Struct.new(:bar, :baz) do
  def foo
  end
end

It completes:

• Struct attributes
• Struct initialise method with appropriate args or kwargs based on keyword_init option
• Struct instance variables
• Utilises @param yard tags on class definition to infer attribute types.
  • While this is not a YARD specification, I think it avoids quite some boilerplate that comes from @!attribute usage, which kind of defeats the purpose of Struct usage to avoid defining them by hand in the first place.

     class Foo < Struct.new(:bar, :baz)
       # @!attribute [rw] bar
       #   @return [String]
       # @!attribute [rw] baz
       #   @return [Integer]
       def foo
       end
     end

Approach

So I thought for quite a while, where this code could live, and I went back and forth many times between:

• Adding it to the lib/solargraph/parser/parser_gem/node_processors
  • However, Struct.new is not a language construct, ie, node per se.
• Adding it to the lib/solargraph/convention (direction I went with)
  • However, the code here mainly needs to hook into the parsing stage, rather than implement the Solargraph::Convention interface.

So, as we see, each approach has its upside/downside. I ultimately went with the second approach because while working on the solargraph-rspec plugin, I always felt a need for Solargraph to provide a way to hook into the parsing phase. Something that would prevent plugins from parsing the same code twice!

While I attempted to allow supporting multiple node processers, I stumbled over some issues with having "duplicate pins", which I couldn't find a good solution to, so I ended up with this "hybrid solution", hoping that we get to solve that problem eventually (which is why I left the TODO comments are for)

I plan to add support similarly for Data classes too, before jumping to that I wanted to got some feedback from you on the proposed approach and whether this any sense at all to you?

Thanks in advance for your thoughts and guidance!

[lekemula]

Are clip_specs the right place for these specs?

[castwide]

The Clip specs are pretty heavy, but I can understand why. They're fine here for now. I'm planning updates to Chain that make it less reliant on Clip features. Part of that change will probably include moving some tests from clip_spec to chain_spec or the various link specs.

[lekemula]

I don't like the fact that I had to change the node processor classes - do you see a better way to avoid that?

My initial attempt was to allow multiple node processors, as I explained in the PR description.

[castwide]

I suspect that any solution would have required some sort of change to node processors. At the very least, they would need a mechanism to map anonymous class pins for declarations like class Foo < Struct.new. I'm good with handling it like this for now. We can try exploring more general solutions when we look into adding support for Data.

[lekemula]

Sounds good 🙌!

[castwide]

👍