parse difference for heredoc with multiple consecutive line continuations

[froydnj]

I think this is like #2842, but with more line continuations:

description = <<~EOS
  This line\
  \
  Another line.

  Extra rationale.
EOS

bin/prism ripper gives:

Ripper:
[:program,
 [:stmts_add,
  [:stmts_new],
  [:assign,
   [:var_field, [:@ident, "description", [1, 0]]],
   [:string_literal,
    [:string_add,
     [:string_add,
      [:string_add, [:string_add, [:string_add, [:string_content], [:@tstring_content, "This line\\\n", [2, 2]]], [:@tstring_content, "  \\\n", [3, 0]]], [:@tstring_content, "Another line.\n", [4, 2]]],
      [:@tstring_content, "\n", [5, 0]]],
     [:@tstring_content, "Extra rationale.\n", [6, 2]]]]]]]
Prism:
[:program,
 [:stmts_add,
  [:stmts_new],
  [:assign,
   [:var_field, [:@ident, "description", [1, 0]]],
   [:string_literal,
    [:string_add,
     [:string_add, [:string_add, [:string_add, [:string_content], [:@tstring_content, "  This line\\\n", [2, 0]]], [:@tstring_content, "Another line.\n", [4, 2]]], [:@tstring_content, "\n", [5, 0]]],
     [:@tstring_content, "Extra rationale.\n", [6, 2]]]]]]]
Output is not identical

The second line continuation is nowhere to be found in the prism output. I'm not sure how deeply you care about this, given that the ultimate output is unchanged, but it was a little surprising that the parse tree didn't really correspond to the source for this bit.

Found while debugging fables-tables/rubyfmt#772. (cc @reese)

[kddnewton]

I'm not sure if I should consider this a bug in our ripper translation layer or our AST. I could see a case for inserting an empty string node that contains the content. I'll take a look.

[froydnj]

I could have been clearer in my description -- the second line continuation doesn't even show up in bin/prism parse output, so I think this is definitely an AST issue.

[kddnewton]

Yeah, I mean it's an issue insofar as you're trying to recreate the original source, not for use cases like compilers since it doesn't impact the actual value of the string.

Until this is fixed, you can probably use the fact that when subsequent string parts are not continuous you know there's an empty string that was dropped from the output.

But still, happy to add in the empty string node.