Adds support for interpolated strings to HEREDOC#121
Adds support for interpolated strings to HEREDOC#121aryx merged 4 commits intotree-sitter:masterfrom
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
169fc16 to
42ecf1a
Compare
|
Empty heredocs don't seem to work: |
|
Also, this fails to parse: |
|
Also, lines with only whitespace fail to parse: The line between "hello" and "world" contains a single space. |
…sistency after the introduction of encapsed strings
|
Thanks for testing, @Sjord The issues has been fixed and your excellent edge cases has been added to the test suite. |
|
Thanks. I have tested some more and came up with some more edge cases:
|
|
Nice finds! Testing is something I'm working on becoming better at, so thank you for the "lesson" 🙂 I'm unable to add a test for the carriage return version since git seems to be converting my line endings 🙁 However, all bugs has been fixed. I've added CR as a choice in_new_line since that's how Notepad++ interprets it and how Mac OS handled line endings until 2002. |
|
Thanks. I have found some more nowdocs that fail to parse. In particular, a nowdoc with an empty line: Also, with \x0b, \x0c or \x0d on a line. |
|
Thanks! Given that I've understood the issues correctly, they're all fixed in the latest commit. |
|
Confirmed, everything works. I see I was a little bit unclear with the hex values in my last message. With \x0b I meant the byte which hexadecimal representation is |
Adds support for:
Issues
In order to not have
text_interpolationkick in whenever?>or<?is seen in heredocs (could be across heredocs),I've had to add these as tokens in
_interpolated_string_body_heredocto be aliased asstring_value. This feels ugly andshould be unneccessary, but I've yet to find a way around it with what limited time I'm able to devote at the moment. Any
suggestions would be most welcome!
Checklist: