Feature request: DSL compiler for RuboCop's `def_node_matcher`

[amomchilov]

This code:

class MyCop < ::RuboCop::Cop::Base
  def_node_matcher :my_pattern?, <<~PATTERN
    (send _ :some_method ...)
  PATTERN
end

Should produce this RBI:

class MyCop < ::RuboCop::Cop::Base
  sig do
    params(
      node: RuboCop::AST::Node,
      block: T.proc.params(*captures: T.untyped).void,
    ).returns(T::Boolean)
  end
  def my_pattern?; end
end

Typing the block would be pretty challenging... we'd need to statically analyze the NodePattern, to figure out how many matches where will be. I just left it as an untyped varargs.

[dduugg]

I created a somewhat hacky one for Homebrew that you may find helpful as a starting point: https://github.com/Homebrew/brew/blob/main/Library/Homebrew/sorbet/tapioca/compilers/rubocop.rb

[Vein05]

Hi! I'd love to work on this if it's still available.

I used the Homebrew's compiler as a starting point(thanks dduugg), but noticed it relies on method_source for source inspection which seemed a bit unorthodox to me.

I also took a look at method_definer.rb in rubocop-ast, and was wondering whether using source_location could avoid the extra dependency, or whether a small tracking layer around NodePattern::Macros would be a cleaner direction.

I've developer experience, but still fairly new to Ruby, so I wanted to check if there's a preferred approach here before I start. I'm open to suggestions.

Thanks!

[Vein05]

@egiurleo hey, just wanted to check upon on this!

[KaanOzkan]

@Vein05 I don't think we have a preferred approach but feel free to explore and propose what you think is the best.

An alternative approach could be to see if Rubocop is registering these DSL calls anywhere. If there's a data structure that is populated and carries the information that "this is a def node matcher" it'll be useful. If it doesn't exist we could also try patching Rubocop and registering necessary information ourselves from a callsite during a tapioca dsl run. If gathering the information in runtime is faster than reading the source it'd be preferred.

[Vein05]

@KaanOzkan Thanks for the help with that I was having a hard time thinking about what would be the best way to look at it.

The monkey patch idea would be hard to implement as by the time tapioca loaded cop classes would already be defined, but I did find param0 and source_location points to the macro call present in the def_helper.

I came up with a hybrid solution to use param0 for fast runtime filtering, then read the source line to confirm and extract the pattern. The prototype I ran identified all 400 macro methods across 216 cops, correctly classified matcher vs search, and extracted capture counts.

Do you think this approach would be good for this case? Open for suggestions!

[KaanOzkan]

@Vein05 yes that sounds okay at first glance, feel free to open a PR. Thanks.