Ruby dot call syntax accepts errant extra set of arguments

[haileys]

The grammar accepts the following code:

x.(123)(456)

And produces the following syntax tree:

(program [0, 0] - [1, 0]
  (method_call [0, 0] - [0, 12]
    (call [0, 0] - [0, 7]
      (identifier [0, 0] - [0, 1])
      (argument_list_with_parens [0, 2] - [0, 7]
        (integer [0, 3] - [0, 6])))
    (argument_list [0, 7] - [0, 12]
      (integer [0, 8] - [0, 11]))))

This is because the call rule accepts dot-call syntax including argument list, but method_call unconditionally sequences call with another argument list:

call: $ => prec.left(PREC.BITWISE_AND + 1, seq(
  $._primary,
  choice('.', '&.'),
  repeat($.heredoc_end),
  choice($.identifier, $.operator, $.constant, $.argument_list_with_parens)
)),

method_call: $ => {
  const receiver = choice($._variable, $.scope_resolution, $.call)

  return choice(
    seq(receiver, $.argument_list),
    seq(receiver, prec(PREC.CURLY_BLOCK, seq($.argument_list, $.block))),
    seq(receiver, prec(PREC.DO_BLOCK, seq($.argument_list, $.do_block))),
    prec(PREC.CURLY_BLOCK, seq(receiver, $.block)),
    prec(PREC.DO_BLOCK, seq(receiver, $.do_block))
  )
},

By comparison, Ruby rejects the example code:

$ ruby -c -e 'x.(123)(456)'
-e:1: syntax error, unexpected '(', expecting end-of-input
x.(123)(456)
        ^

[maxbrunsfeld]

This is still true.

In general, I don't consider it a huge priority to avoid accepting invalid code, but I'd be open to a change that tightens the grammar in some way to disallow this.