Handle properly stringifying multiline macro expressions

[Blacksmoke16]

Given the following code:

{%
  a = 1
%}

Its to_s representation before this PR:

{% a = 1 %}

and after:

{%
  a = 1
%}

This PR also addresses #15307:

macro finished
  {% verbatim do %}
    {%
      10

      # Foo

      20
    %}
  {% end %}
end

is now properly stringified as:

macro finished
  {% verbatim do %}
    {%
      10



      20
    %}
  {% end %}
end

instead of:

macro finished
  {% verbatim do %}
    {%
      10
      20
    %}
  {% end %}
end

[straight-shoota]

Hm, but if the expression only has a newline at one end it'll be different, right?

{%
  a = 1 %}
{% b = 1
%}

This presumably stringifies to:

{%
  a = 1
%}
{% b = 1 %}

Also other whitespace isn't repeated truthfully either.
So sure this improves some situations. And maybe that means the most common ones are covered correctly. But there are still lots of holes and I'm wondering if it's worth doing this change when it's clearly insufficient to the full extend of the problem space.

[Blacksmoke16]

Hm, but if the expression only has a newline at one end it'll be different, right?

If you have code like:

{%
  a = 1 %}
{% b = 1
%}

and you run the formatter on it, you get:

{%
  a = 1
%}
{% b = 1 %}

So this at least makes things consistent with that.

[Blacksmoke16]

Pushed up another commit to better handle indentation within the stringified nodes. E.g.

macro finished
  {% verbatim do %}
    {%
      10
      20
    %}
  {% end %}
end

Its string representation is now the same, instead of:

macro finished
  {% verbatim do %}
    {%
  10
  20
%}
  {% end %}
end

[Blacksmoke16]

Ended up refactoring things one last time. Realized I could do this without touching the AST representation at all and just handle it based on the start/end location of the nodes themselves. So this PR only touches ToSVisitor now.

[straight-shoota]

I wonder if it could be feasible to keep track of line numbers in the ToSVisitor and add newlines accordingly...? 🤔
This should be possible by memorizing the reference position in @str and counting the \n characters in between.

The implementation would consider each node's location relative to each other. If node.location is on line x and node.exp.location is on line x + n, there need to be n newlines in between. We need to add as many as necessary.
Similarly, after stringifying node.exp, count the number of newlines and add more to match the difference of line numbers between node.location and node.end_location.

[Blacksmoke16]

@straight-shoota I think it should definitely be possible, but would you be opposed to leaving that for another PR to address #15307? This PR is already a good start and is the basis of some other PRs I have in the works.

EDIT: Actually one problem might be that @str in some context doesn't support #pos=. But as long as we don't need to do a #pos= or anything we should be okay.

[straight-shoota]

I'm not super convinced about the implementation in this PR because it just addresses some symptoms, not the problem from the bottom up. It's basically just shifting error cases around, not really solving anything.
It has some benefit because it moves towards better behaviour for well-formatted code which is supposedly more common.
I'd really much more like to resolve the full problem instead of a cosmetic change. IMO this isn't super urgent so we could take some time to explore more effective alternatives.

[Blacksmoke16]

👍 Alright, I'll see about doing another refactor to address #15307 in this PR in that case. I'll mark it as draft for now in that case.

[Blacksmoke16]

Alright @straight-shoota, pushed up another commit that handles significant whitespace as well. Tested against to_s_spec.cr as well as within my other macro code coverage branch's test suite and everything seems to pass so 👍?

EDIT: Nevermind, spoke too soon. Found some additional edge cases I'll need to address.
EDIT2: Okay it was a quick fix 😅.