allow brackets in expression_value nodes

[the-mikedavis]

I found some odd behavior parsing a case like this:

<div phx-value-target={ "##{@id}" }></div>

where the expression_value node has a hard time dealing with the brackets {..}. Here's the parse result:

(fragment [0, 0] - [1, 0]
  (tag [0, 0] - [0, 42]
    (start_tag [0, 0] - [0, 36]
      (tag_name [0, 1] - [0, 4])
      (attribute [0, 5] - [0, 35]
        (attribute_name [0, 5] - [0, 21])
        (expression [0, 22] - [0, 35]
          (ERROR [0, 23] - [0, 27]
            (expression_value [0, 23] - [0, 27]))
          (expression_value [0, 27] - [0, 32])
          (ERROR [0, 32] - [0, 33]))))
    (end_tag [0, 36] - [0, 42]
      (tag_name [0, 38] - [0, 41]))))

I shuffled around the grammar rules for expression_value a bit so we use a hidden $._expression_value which can repeat to capture everything in the expression's brackets. Then we alias those repeating hidden nodes all together as one expression_value node. The tree for that example case ends up looking like so

(fragment [0, 0] - [1, 0]
  (tag [0, 0] - [0, 42]
    (start_tag [0, 0] - [0, 36]
      (tag_name [0, 1] - [0, 4])
      (attribute [0, 5] - [0, 35]
        (attribute_name [0, 5] - [0, 21])
        (expression [0, 22] - [0, 35]
          (expression_value [0, 23] - [0, 34]))))
    (end_tag [0, 36] - [0, 42]
      (tag_name [0, 38] - [0, 41]))))

[connorlay]

Hi @the-mikedavis , thanks for the bug report and PR! I'm going to pull this down and test it this evening. While I am doing that, could you add a test for this edge-cased?

[the-mikedavis]

ah whoops I always forget about the test suite 😅

on it!

[connorlay]

@the-mikedavis Thanks for the tests, this looks great to me.

[connorlay]

🚢

[connorlay]

I like this approach a lot! I'll review the Surface grammar and see if it has the same bug or not. If so I'll port this fix over.