rubocop / rubocop-ast Goto Github PK

Support for Prism was added in rubocop-ast 1.31.0 and marked as "experimental" in the changelog. However, Prism was also added as a runtime dependency in the Gemspec.

It seems contradictory to require a library for an experimental feature, particularly when it's only available in the latest Ruby release.

We're starting to see some failures in our CI pipelines because of this new requirement.

Would you be able to remove Prism as a runtime dependency? Thank you!

I'd like to use the latest version of parser with emit_forward_arg turned on.

We could avoid this "hack" of redefining to_a as different from children

$ ruby-parse --legacy-forward-arg -e "def foo(...);end; def bar(*rest); end"
(begin
  (def :foo
    (forward-args) nil)
  (def :bar
    (args
      (restarg :rest)) nil))

$ ruby-parse -e "def foo(...);end; def bar(*rest); end"
(begin
  (def :foo
    (args
      (forward-arg)) nil)
  (def :bar
    (args
      (restarg :rest)) nil))

The later form is much improved as an argument signature is always inside an args node.

I doubt it would be much incompatibility, but v1 would be perfect for this.

Comments / objections?

If a MethodDispatchNode has a block node as its parent, node.block_node returns that parent block node. However, if it's a numblock, node.block_node returns nil.

Parser has a few ways to emit things that have changed with time: https://github.com/whitequark/parser/#usage

I believe we don't turn any of these on.

I ask the question before v1: should we turn them on (and risk breaking some cops) or keep the compatibility mode like this (until at least v2).

Note that currently there's no way that I know of to use ruby-parse to output the same ast.

$ ruby-parse -e "{}[1] = 2"
(indexasgn
  (hash)
  (int 1)
  (int 2))

$ ruby-parse -e "->{}"
(block
  (lambda)
  (args) nil)

Within RuboCop, it is:

(send
  (hash)
  :[]=
  (int 1)
  (int 2)
)

(block
  (send nil :lambda)
  (args) nil)

I haven't spend much time thinking about it, but at first sight the current mode is typically simpler and doesn't make a distinction between very similar things (e.g. do |x, | vs do |x|, or ->{} vs lambda {}), which is typically what cop writers want. OTOH, if they need to distinguish these (e.g. writing a cop against |x, |), then NodePattern is not sufficient and they will have to check the loc or source themselves.

If we decide not to change, I'll make a PR so that there's a switch for ruby-parse to output the same as RuboCop's.

If we do decide to change, well, we should definitely do it before 1.0 as this might impact cops, as well as existing metrics (e.g. ->{} is not an actual :send so ABC metric is not quite correct)

@rubocop-hq/rubocop-core what say you?

Related to https://github.com/rubocop-hq/rubocop/issues/5999

I'm wondering if we should publish some docs to RTD for the gem or keep things light. I'm guessing some documentation of the key concepts and the existing node extensions would be useful. Right now all we have is a section on NodePattern.

I'm suggesting this mostly because I've noticed in the previous release we forgot to set the docs version in antora.yml. In RuboCop itself the cut_release task does all such updates automatically.

Currently methods & predicates can be called on self:

(_ #predicate?(:arg, %1) ...)
(_ #method(:arg, %1) ...)

Request is to allow calling them on constants:

(_ #Foo.predicate?(:arg, %1) ...)
(_ #Foo::Bar.method(:arg, %1) ...)
(_ #::Global::X.method(:arg, %1) ...)

Consider:

ruby-parse --27 -e "something { _1 }"
(numblock
  (send nil :something) 1
  (lvar :_1))

The count of numbered parameters is returned as a bare integer, which makes it extra resistant to being captured in a node pattern. It's not an int node so int or int_type? don't work, and if I try #is_a?(Integer) I get ArgumentError: wrong number of arguments (given 2, expected 1) for some reason.

Any suggestions?

https://github.com/rubocop/rubocop-ast/blob/master/CHANGELOG.md#1312-2024-03-08

It should check against earliest compatible rubocop as well as the master branch

Again, not a feature request, more like to start the discussion. Can't think of a better place for this discussion again.

As a prolific cop author, I personally find Node Pattern hard to write.

Please speak up if you use some tools, that visually indicate that a node pattern you're trying to craft matches a given set of source excerpts. I can think of this as:

(send {nil? (const :Greeter)} :hello str)

§ hello 'Dear'
§ Greeter.hello ''
§ hello 'world'
§ hello 1
§ hello

Think visual regexp matcher we got used to already.

I recall there are Regexp generators that build a minimal Regexp to match a given set of strings (and always returns .* haha).
Wondering if building a similar tool to automatically build node pattern given some code samples it should match, and some that it should not.

Unfortunately, I'm not aware of the principles of building such a tool. Do you have an idea of where to start?

Expected behavior

Have callbacks available for whitequark/parser@7d72eba and _type?

Actual behavior

Above callbacks don't seem to be called for appropiate nodes

Steps to reproduce the problem

module RuboCop
  module Cop
    module Deprecation
       class MutatedStrings < Cop
           MSG = "Don't mutate strings!"
           
           def on_indexasgn(node)
              binding.pry
           end
        end
       end
    end
  end
end

And a quick test with:

  it 'register an offense when indexed assignment is being used on a string' do
    expect_offense(<<~RUBY)
      foo[1] = 'c'
    RUBY
 end

It appears that the callback is not being called, nor a node as indexasgn_type? available

RuboCop version

$ rubocop -V
0.57.2 (using Parser 2.5.1.0, running on ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]

I am fairly new to ruby and definitely to rubocop, so excuse the issue / vs potential PR, I would love to contribute with some tips!.

1. Handle all node types (even unknown ones)
2. Optimize

• avoid locating the symbols all the time
• on_send can be optimized; others "custom" ones should be removed.

When cloning the current head, running a 'gem build rubocop-ast.gemspec', causes the following error:
ERROR: While executing gem ... (Gem::InvalidSpecificationException)
["lib/rubocop/ast/node_pattern/lexer.rex.rb", "lib/rubocop/ast/node_pattern/parser.racc.rb"] are not files

(These are currently missing from the ast/node_pattern folder).

As a work around, I renamed the existing files that I think correspond, but either a) need to point to the updated files, or b) need to rename/create the correct files.

This is using Ruby 2.7 on a windows machine.

Numbered Parameters feature has been introduced since 2.7.
The new node type, numblock, will be supported by rubocop/rubocop#7665, but we still need to modify cops that use on_block or block_type? methods.

For example, Style/BlockDelimiters cop does not work for numblock even if the pull request is merged.

# with TargetRubyVersion: 2.7, and the PR.

# The cop adds an offense to the following code.
items.each do |item| item / 5 end 

# The cop does not add an offense but it should.
items.each do _1 / 5 end

In this case, I guess we can add alias on_numblock on_block to the cop. And we can probably add the same code to the similar cops.

And I guess we also need to modify Node#block_type? method call.
I guess we can extend numblock node with BlockNode extension.

Expected behavior

Cops that work for block should work for numblock also.

Actual behavior

It does not work well even with rubocop/rubocop#7665

Steps to reproduce the problem

For Stlye/BlockDelimiters example, we can reproduce the problem with the following commands.

• Install RuboCop with rubocop/rubocop#7665
• Put .rubocop.yml with TargetRubyVersion: 2.7
• Put the example as a Ruby file
• Execute RuboCop

And we can find the potential target cops with git grep.

$ git grep on_block
lib/rubocop/ast/traversal.rb:      def on_block(node)
lib/rubocop/cop/layout/access_modifier_indentation.rb:        alias on_block  on_class
lib/rubocop/cop/layout/block_alignment.rb:        def on_block(node)
lib/rubocop/cop/layout/block_end_newline.rb:        def on_block(node)
lib/rubocop/cop/layout/empty_lines_around_access_modifier.rb:        def on_block(node)
lib/rubocop/cop/layout/empty_lines_around_block_body.rb:        def on_block(node)
lib/rubocop/cop/layout/indentation_width.rb:        def on_block(node)
lib/rubocop/cop/layout/multiline_block_layout.rb:        def on_block(node)
lib/rubocop/cop/layout/space_around_block_parameters.rb:        def on_block(node)
lib/rubocop/cop/layout/space_around_keyword.rb:        def on_block(node)
lib/rubocop/cop/layout/space_before_block_braces.rb:        def on_block(node)
lib/rubocop/cop/layout/space_inside_block_braces.rb:        def on_block(node)
lib/rubocop/cop/lint/next_without_accumulator.rb:        def on_block(node)
lib/rubocop/cop/lint/non_deterministic_require_order.rb:        def on_block(node)
lib/rubocop/cop/lint/redundant_with_index.rb:        def on_block(node)
lib/rubocop/cop/lint/redundant_with_object.rb:        def on_block(node)
lib/rubocop/cop/lint/useless_access_modifier.rb:        def on_block(node)
lib/rubocop/cop/lint/void.rb:        def on_block(node)
lib/rubocop/cop/metrics/block_length.rb:        def on_block(node)
lib/rubocop/cop/metrics/method_length.rb:        def on_block(node)
lib/rubocop/cop/mixin/method_complexity.rb:      def on_block(node)
lib/rubocop/cop/naming/block_parameter_name.rb:        def on_block(node)
lib/rubocop/cop/naming/variable_name.rb:        alias on_blockarg  on_lvasgn
lib/rubocop/cop/style/block_delimiters.rb:        def on_block(node)
lib/rubocop/cop/style/collection_methods.rb:        def on_block(node)
lib/rubocop/cop/style/each_for_simple_loop.rb:        def on_block(node)
lib/rubocop/cop/style/each_with_object.rb:        def on_block(node)
lib/rubocop/cop/style/empty_block_parameter.rb:        def on_block(node)
lib/rubocop/cop/style/empty_lambda_parameter.rb:        def on_block(node)
lib/rubocop/cop/style/for.rb:        def on_block(node)
lib/rubocop/cop/style/inverse_methods.rb:        def on_block(node)
lib/rubocop/cop/style/lambda.rb:        def on_block(node)
lib/rubocop/cop/style/method_called_on_do_end_block.rb:        def on_block(node)
lib/rubocop/cop/style/multiline_block_chain.rb:        def on_block(node)
lib/rubocop/cop/style/multiline_block_chain.rb:            # found by subsequent calls to on_block.
lib/rubocop/cop/style/next.rb:        def on_block(node)
lib/rubocop/cop/style/proc.rb:        def on_block(node)
lib/rubocop/cop/style/redundant_begin.rb:        def on_block(node)
lib/rubocop/cop/style/redundant_self.rb:        def on_blockarg(node)
lib/rubocop/cop/style/redundant_self.rb:        def on_block(node)
lib/rubocop/cop/style/redundant_sort_by.rb:        def on_block(node)
lib/rubocop/cop/style/single_line_block_params.rb:        def on_block(node)
lib/rubocop/cop/style/symbol_proc.rb:        def on_block(node)

$ git grep -F block_type?
lib/rubocop/ast/node/mixin/method_dispatch_node.rb:        parent&.block_type? && eql?(parent.send_node)
lib/rubocop/cop/lint/ambiguous_block_association.rb:          send_node.last_argument.block_type? &&
lib/rubocop/cop/lint/assignment_in_condition.rb:          return if node.condition.block_type?
lib/rubocop/cop/lint/shadowed_argument.rb:          node.conditional? || node.block_type? ||
lib/rubocop/cop/metrics/block_nesting.rb:          count_blocks? && node.block_type?
lib/rubocop/cop/mixin/multiline_expression_indentation.rb:          break false if a.block_type?
lib/rubocop/cop/mixin/multiline_expression_indentation.rb:          ancestor.block_type? && part_of_block_body?(candidate, ancestor)
lib/rubocop/cop/style/auto_resource_cleanup.rb:            (parent && (parent.block_type? || !parent.lvasgn_type?))
lib/rubocop/cop/style/inverse_methods.rb:          if node.block_type?
lib/rubocop/cop/style/method_call_with_args_parentheses/omit_parentheses.rb:            parent = node.parent&.block_type? ? node.parent.parent : node.parent
lib/rubocop/cop/style/method_called_on_do_end_block.rb:          return unless receiver&.block_type? &&
lib/rubocop/cop/style/multiline_block_chain.rb:            next unless receiver&.block_type? && receiver&.multiline?
lib/rubocop/cop/style/parallel_assignment.rb:          node.block_type? || node.send_type?
lib/rubocop/cop/style/redundant_parentheses.rb:          !ancestor.begin_type? && !ancestor.def_type? && !ancestor.block_type?
lib/rubocop/cop/style/safe_navigation.rb:          receiver = if method_chain.block_type?
lib/rubocop/cop/variable_force/variable.rb:          argument? && @scope.node.block_type?
lib/rubocop/cop/variable_force/variable_table.rb:            return nil unless scope.node.block_type?
lib/rubocop/cop/variable_force/variable_table.rb:            break variables unless scope.node.block_type?
lib/rubocop/cop/variable_force/variable_table.rb:          return unless current_scope.node.block_type?
spec/rubocop/ast/send_node_spec.rb:      it { expect(send_node.block_node.block_type?).to be(true) }
spec/rubocop/ast/super_node_spec.rb:      it { expect(super_node.block_node.block_type?).to be(true) }

RuboCop version

master (with rubocop/rubocop#7665 )

We need a struct_constructor? matcher (see #8122)
A more general "class_definition?matcher that would matchclass Foo < Bar, Struct.new(...) doandClass.new(...) do` would be nice too

In the Using node matcher macros section of the docs, following the links to def_node_matcher and def_node_search result in Oops, We Couldn't Find That Page on rubydoc.info

See rubocop/rubocop#9138 (comment)

It will capture calls without parameters:

RuboCop::ProcessedSource.new('do_something_with attr, asdf', RUBY_VERSION.to_f).ast.children[2].attribute_accessor? # => [:attr, []]

I suspect the pattern should be changed to something like:

(send nil? ${:attr_reader :attr_writer :attr_accessor :attr} $({sym str} _)+)

Do we need a node to help with “multi-assignment”? I came across this code in the rubocop-thread_safety gem: https://github.com/rubocop/rubocop-thread_safety/blob/2662a8142f41a53bc3bc65eb2c670db18b3c581a/lib/rubocop/cop/thread_safety/mutable_class_instance_variable.rb#L99C13-L110

def on_masgn(node)
  return unless in_class?(node)

  mlhs, values = *node
  return unless values.array_type?

  mlhs.to_a.zip(values.to_a).each do |lhs, value|
    next unless lhs.ivasgn_type?

    on_assignment(value)
  end
end

RuboCop’s InternalAffairs/NodeDestructuring cop tells me to “Use the methods provided with the node extensions instead of manually destructuring nodes” on the mlhs, values = *node line. But the RuboCop::AST::Node class doesn’t really offer any specialised helper method for this type of node.

So I thought it may be useful to add a RuboCop::AST::MasgnNode class with access to the left-hand-side list (also a RuboCop::AST::Node instance) and the right-hand-side RuboCop::AST::ArrayNode of values? And perhaps the class could also have a method to iterate over each assignment pair, much like the mlhs.to_a.zip(values.to_a).each, though perhaps it should be lazy instead of eager.

That method and dependents need to move to main Rubocop

def_node_pattern :method_call?, 'some pattern'
# equivalent to:
def method_call?(node = self, arg1)
  # ...
end

### Should we change to
# general case:
def method_call?(node0, arg1) 
  node0.is_a?(Node) && # ...
end
# on `Node` class, or if `on_self: true`:
def method_call?(arg1)
  self.is_a?(Node) &&  # ...
end

This makes it easier to call with a positional argument Nevermind, I wasn't thinking straight. I realized this only after doing the work 🤷‍♂️

This makes it clear when a method is using self or when an argument is required. Currently it isn't and I believe that cop.some_matcher?() will return false instead of raising an error.

Potential incompatibilities would be on extensions of our Node via a module (this would require on_self: true), or if these matchers are used sometimes with given argument. I found two such uses in our code base.

This is more of a question than a feature request.
In rubocop-rspec's cops there are two patterns have redundancy.

1. RSpec/SubjectStub

{
  (block (send nil? :subject (sym $_)) ...)
  (block (send nil? $:subject) ...)
}

It is supposed to capture :subject or the subject's name from:

subject { ... }
# or
subject(:name) { ... }

What makes me think it's redundant?

• an equal number of captures
• same wrapping, e.g. base of the tree is the same

What makes it impossible to turn this into:

(block
  (send nil?
    {
      :subject (sym $_)
      $:subject
    }
  )
  ...
)

is that {} would consider all three expressions as matching options, and there is no way (that I'm aware of) to match two or more subsequent nodes that do not compose a complete sequence (terminology may be distorted, hope the idea is clear though).

2. The same applies to another cop, RSpec/DescribeClass:

          (block
            [  (send #{RSPEC} :describe $[!const !#string_constant?] ...)
              !(send #{RSPEC} :describe ... (hash <#rails_metadata? ...>)) ]
            ...
          )

It can't be:

(block
  (send #{RSPEC} :describe
    [
      $[!const !#string_constant?] ...
      ... !(hash <#rails_metadata? ...>)
    ]
  )
  ...
)

because there's no way to combine those (newline-separated) elements into tuples.

I would really prefer to keep Node Pattern syntax simple. And, unlike the previously introduced unordered sequence (<>) there's much of a compelling benefit since I could only find two cops that would just slightly (and arguably) benefit from that.

On the other hand, <> is present already, but it disregards the order. Maybe it's possible somehow to respect the order given some specifier?
Not a real proposal, just thinking aloud:

(block (send nil? { <- :subject (sym $_)> $:subject } ) ... )

(Couldn't compile due to invalid token "<".)

(block
  (send #{RSPEC} :describe
     <- $[!const !#string_constant?] ...>
    !<- ... (hash <#rails_metadata? ...>)>
  ) ...)

where <- > is an "ordered sequence".

I didn't look much into RuboCop core's cops, can't estimate if any of them could benefit from such syntax.

Now that we have a separate gem for rubocop-ast, maybe it's time we move NodePattern out of the RuboCop namespace and into the gem namespace. WDYT? 🙂

👋 Hey all, thanks for this amazing tool.
I'm opening this issue after speaking privately with @bbatsov.

Could you please cover in documentation the basics of how to compose a pattern?

Existing examples like the following give hints on how patterns should be composed, but often the intuitions don't work, leading frustrating trial and error sessions.

(_type int _ str)

I assume that the first token in a pattern is the type, that should correspond to the node type (e.g. send), but what's next? Why often do I see nil? right after? What's $...? Probably a variadic capture.

Could you please help covering the basics of patterns? Thank you 🙏

See rubocop/rubocop@f4f42a2

(block _ $(args (arg _var)) (send (lvar _var) $_))

I was not aware that in a pattern like this, _var acts as a backreference when repeated (ie. the second _var has to match the first _var), which caused the issue in rubocop/rubocop#9257.

It'd be great to have something in the node pattern docs to explain that.

The complete rewrite link at https://github.com/rubocop-hq/rubocop-ast/blob/master/CHANGELOG.md#new-features links to https://docs.rubocop.org/rubocop-ast/node_pattern_compiler.html, which is a 404

Just a reminder for us to do it. Ideally it should happen alongside RuboCop 1.0, but that's not a hard requirement.

I don't think there's anything blocking us from doing 1.0 at any moment.

This could make it easy to distinguish true, false, nil, Integers, Rationals, Complex numners, static regex, constant Strings & Symbols

And avoid things like jruby/jruby#6414 ...

Last Ruby Weekly mentioned https://github.com/lib-ruby-parser/lib-ruby-parser, a replacement for Ripper/parser.
But it has no Ruby bindings yet. Ruby bindings are WIP though.

lib-ruby-parser mentions that

AST is strongly typed, and so if something is nullable it's explicitly defined and documented

I am not certain if it's good or would get us any benefits.

It slipped my mind why rubocop itself still depends on parser? Is it for rewriting?

I imagine such a tool to be external since there's no central storage for node patterns. Most probably even external to rubocop-ast, but I couldn't think of a better place to discuss it.

That, given the two node patterns, e.g.:

(block (send (const {nil? cbase} :MyClass) :hello))

(block (send (const {nil? cbase} :MyClass) :goodbye))

would report:

Node patterns at file1.rb:32 and file2.rb:56 have {(const {nil? cbase} :MyClass) nil?} in common. Consider extracting to a helper method/node pattern.

That would make it possible to simplify those two:

(block (send #myclass :hello))

(block (send #myclass :goodbye))

with an extracted

def_node_matcher :myclass, '(const {nil? cbase} :MyClass)'

Picked this idea up from factor-lang's similarity detector.
Since the node pattern itself can be parsed into an AST, detecting trivial and complete matches should be trivial enough.

I can think of more complex similarity detections.

Start from #177

This spec passes but is strange behaviour:

RSpec.describe RuboCop::AST::ProcessedSource do
  describe '#ast_with_comments' do
    include RuboCop::AST::Sexp

    let(:source) do
      <<~RUBY
        # comment 1
        do_a
        # comment 2
        do_b
        # comment 3
        do_a
      RUBY
    end

    it do
      expect(processed_source.ast_with_comments).to include(
        s(:send, nil, :do_a) => [instance_of(Parser::Source::Comment), instance_of(Parser::Source::Comment)],
        s(:send, nil, :do_b) => [instance_of(Parser::Source::Comment)]
      )
    end
  end
end

Here is the actual hash created:

{
  s(:send, nil, :do_a) => [
    #<Parser::Source::Comment ast/and_node_spec.rb:1:1 "# comment 1">,
    #<Parser::Source::Comment ast/and_node_spec.rb:5:1 "# comment 3">
  ],
  s(:send, nil, :do_b) => [
    #<Parser::Source::Comment ast/and_node_spec.rb:3:1 "# comment 2">
  ]
}

Because there are two s(:send, nil, :do_a) nodes, both comments are associated with the same node in the hash, and then when this is used in rubocop (for instance CommentsHelp.begin_pos_with_comment), it returns potentially the wrong comment node.

I don't know that there is a good way to fix this necessarily without changing how the keys are constructed; this might also not be a RuboCop::AST bug directly either.

I was trying to DRY up a pattern for a PR in rubocop-performance and the NodePattern docs suggest that you can use %CONST with a Set. However, given that rubocop still supports ruby 2.4 I don't believe this is a good recommendation, because Set#=== does not exist in 2.4, and the pattern therefore fails to match there.

For example: https://app.circleci.com/pipelines/github/rubocop-hq/rubocop-performance/341/workflows/528ddd46-d4f6-4dc5-883c-fc02cc002540/jobs/2155

The pattern:

CANDIDATE_METHODS = Set[:select, :find_all, :filter]

def_node_matcher :detect_candidate?, <<~PATTERN
  {
    (send $(block (send _ %CANDIDATE_METHODS) ...) ${:first :last} $...)
    (send $(block (send _ %CANDIDATE_METHODS) ...) $:[] (int ${0 -1}))
    (send $(send _ %CANDIDATE_METHODS ...) ${:first :last} $...)
    (send $(send _ %CANDIDATE_METHODS ...) $:[] (int ${0 -1}))
  }
PATTERN

I wonder if we can refine sets for 2.4 inside NodePattern to add #=== to it? Alternately, should Sets just not be used in rubocop patterns until 2.4 support is dropped? I was considering changing my constant to Set[...].method(:include?).to_proc but that just feels ugly to me.

Background

According to the documentation, the following is possible:

def_node_matcher :global_const?, '(const {nil? cbase} %1)'
def_node_matcher :class_creator, '(send #global_const?({:Class :Module}) :new ...)'

where the argument to the predicate is {:Class :Module}.

Problem

I have a case with a number of similar node matchers, where I'd love to extract the common part:

def_node_matcher :expectation_with_return_block, <<~PATTERN
  (send
    (send nil? :expect ...) :to
    $(block #message_expectation? args _)
  )
PATTERN

def_node_matcher :expectation_with_configured_response, <<~PATTERN
  (send
    (send nil? :expect ...) :to
    $(send #message_expectation? #configured_response? _)
  )
PATTERN

The cop in question rubocop/rubocop-rspec#226

What I did

def self.expectation_with(matcher)
  "(send (send nil? :expect ...) :to #{matcher})"
end

def_node_matcher :expectation_with_return_block, expectation_with(<<~PATTERN)
    $(block #message_expectation? args _)
PATTERN

What I would love to do

def_node_matcher :expectation, <<~PATTERN
  (send (send nil? #{Expectations::ALL.node_pattern_union} ...) :to %1)
PATTERN

def_node_matcher :expectation_with_return_block, <<~PATTERN
  (#expectation(
    $(block #message_expectation? args _)
  ))
PATTERN

But it doesn't work this way. Doesn't seem that the capture is the culprit.

I might be doing it wrong, however. Or this might be too expensive to implement. In either case please feel free to close this - my current approach with expectation_with works quite fine already.

E.g. TRUTHY_LITERALS

Although there's not much valid reason to use them directly, this could break some code relying on them, e.g. [...] - Set[...] TypeError (no implicit conversion of Set into Array), so v1 might be a good time...

At the very minimum we need some page similar to that one https://docs.rubocop.org/rubocop-ast/node_pattern.html

We should probably mention somewhere in the docs that in effect this gem is an extension to the ast and parser gems. Right now users will certainly struggle to understand this, as our library overview is 5 lines long. :-)

I'm getting the error message:

undefined method `emit_forward_arg=' for RuboCop::AST::Builder:Class (NoMethodError)

with the parser v2.7.0.2 gem. If I update to parser v3 the error goes away.

• ruby 2.6.6
• rubocop 1.7.0
• rubocop-ast 1.3.0

Full trace:

Traceback (most recent call last):
	15: from /home/my_home/.rvm/gems/ruby-2.6.6/bin/ruby_executable_hooks:24:in `<main>'
	14: from /home/my_home/.rvm/gems/ruby-2.6.6/bin/ruby_executable_hooks:24:in `eval'
	13: from /home/my_home/.rvm/gems/ruby-2.6.6/bin/rubocop:23:in `<main>'
	12: from /home/my_home/.rvm/gems/ruby-2.6.6/bin/rubocop:23:in `load'
	11: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-1.7.0/exe/rubocop:6:in `<top (required)>'
	10: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-1.7.0/exe/rubocop:6:in `require'
	 9: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-1.7.0/lib/rubocop.rb:14:in `<top (required)>'
	 8: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-1.7.0/lib/rubocop.rb:14:in `require'
	 7: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop-ast.rb:3:in `<top (required)>'
	 6: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop-ast.rb:3:in `require_relative'
	 5: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast.rb:81:in `<top (required)>'
	 4: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast.rb:81:in `require_relative'
	 3: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast/builder.rb:3:in `<top (required)>'
	 2: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast/builder.rb:4:in `<module:RuboCop>'
	 1: from /home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast/builder.rb:16:in `<module:AST>'
/home/my_home/.rvm/gems/ruby-2.6.6/gems/rubocop-ast-1.3.0/lib/rubocop/ast/builder.rb:17:in `<class:Builder>': undefined method `emit_forward_arg=' for RuboCop::AST::Builder:Class (NoMethodError)

With the latest version of the gem I receive the following error when executing rubocop:
An error occurred while Layout/LineLength cop was inspecting /home/jonny/Programming/myapp/app/workers/bot.rb:330:8.

          I put an initial version of a live debugger at https://nodepattern.herokuapp.com/

Originally posted by @marcandre in #81 (comment)

I have used this site often when writing custom cops, any chance this can be deployed again ?