Consider if syntax error caused an unexpected variable instead of end

[mauro-oto]

Consider tIDENTIFIER in Ruby 2.6 and local variable or method in Ruby 2.7 and 3.0

dead_end was showing just the syntax error, but not the banner:

➜   dead_end datadog.rb

file: /Users/mauro-oto/Projects/dead_end/datadog.rb
simplified:

       4  Datadog.configure do |c|
    ❯  5    ["rails", "grpc"].each do |service
    ❯ 11    end
      12  end

With the fix:

➜  dead_end datadog.rb

DeadEnd: Unmatched `|` character detected

Example:

  `do |x` should be `do |x|`

file: /Users/mauro-oto/Projects/dead_end/datadog.rb
simplified:

       4  Datadog.configure do |c|
    ❯  5    ["rails", "grpc"].each do |service
    ❯ 11    end
      12  end

[mauro-oto]

@schneems I noticed you are not really using context in the specs, would you prefer to keep these separate?

[schneems]

My experience with contexts is that they become large and unwieldy and lose their usefulness and then when tests get moved around the indentation makes the diff larger. I'm not strictly against it though.

[schneems]

This looks great. I gave one comment on an alternate implementation. Let me know what you think.

[schneems]

What do you think about adding a case statement above the unexpected end case. Something like:

when /unexpected .* expecting '(?<unmatched_symbol>.*)/
  match = $LAST_MATCH_INFO
  @unmatched_symbol = match[:unmatched_symbol].to_sym
  @error_symbol = :unmatched_syntax

I'm wondering if that will allow us to simplify this a bit. My worry is the larger this case becomes the more likely accidentally firing this logic on an unrelated parse error becomes larger. By moving the "expecting " logic above this case in the detection, we can avoid trying to catch some of these seemingly unrelated other exception types.

[mauro-oto]

@schneems thanks, updated! Let me know what you think.

I checked and the only one that doesn't match that regexp now is unexpected `end' so I left that one there, and the rest are covered by that new regexp now 👍

Also had to use $1 instead, because for some reason $LAST_MATCH_INFO comes back as nil 🤔

[mauro-oto]

So I had to also leave the cases for 2.5 and 2.6, although we could use a regex there too.. what do you think?

[schneems]

This is great, exactly what I had in mind