Handle active support concern's recursive nature

[vinistock]

This might require some infrastructure changes and new APIs in the Ruby LSP side, but we came to realize that there's one aspect of concerns we are unable to match with the current approach.

If a concern includes another concern which defines class methods, those class methods are recursively extended to all other including concerns. For example:

module ConcernWithClassMethods
  extend ActiveSupport::Concern

  module ClassMethods
    def foo; end
  end
end

module OtherConcern
  extend ActiveSupport::Concern
  include ConcernWithClassMethods
end

OtherConcern.foo # ok!

module YetAnotherConcern
  extend ActiveSupport::Concern
  include OtherConcern
end

YetAnotherConcern.foo # ok!

class Bar
  include YetAnotherConcern
end

Bar.foo # ok!

This is a bit challenging to fix with our current architecture because ancestor linearization is done all lazily for better performance and in this particular example, ancestors of the attached class alter the ancestors of the singleton class.

That is, you need to linearize the ancestors of Bar to discover that Bar::<Class:Bar> inherits from ConcernWithClassMethods::ClassMethods. We may need some way to have concerns mark the namespaces that include them with some flag telling the algorithm that, for those namespaces, you have to first linearize the attached class in order to accurately linearize the singleton class.

[body-clock]

I think I'm experiencing the result of this bug. I really want hover docs on something like Record.create!(...) (on the .create! method) but the method is defined in ActiveRecord::Persistence::ClassMethods. This means I don't get any docs/intellisense for a good handful of ActiveRecord methods which is a bummer. Has there been any progress made here?

[vinistock]

Fixing this will require changing or exposing new APIs from the Ruby LSP as this behaviour cannot currently be represented in the index.

[body-clock]

I actually started to get hover docs/intellisense after ensuring the ruby-lsp-rails was coming up successfully. It can be quite difficult to debug given the log level required to see output in Neovim :LspLog. I'm investigating ways to make this easier.