Format code in comments following # =>

[fschrfl]

Implements the feature discussed in #7272.

Using the same example as in the issue:

a = [1, 2, 3]
a.permutations    # => [[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]
a.permutations(1) # => [[1],[2],[3]]
a.permutations(2) # => [[1,2],[1,3],[2,1],[2,3],[3,1],[3,2]]
a.permutations(3) # => [[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]
a.permutations(0) # => [[]]
a.permutations(4) # => []

The above is now formatted like this:

a = [1, 2, 3]
a.permutations    # => [[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]]
a.permutations(1) # => [[1], [2], [3]]
a.permutations(2) # => [[1, 2], [1, 3], [2, 1], [2, 3], [3, 1], [3, 2]]
a.permutations(3) # => [[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]]
a.permutations(0) # => [[]]
a.permutations(4) # => []

Note that the last two lines are no valid Crystal expressions in which case the formatter doesn't change them.

This is my first attempt at a contribution to the project so if I did anything wrong please let me know and I will try to improve.

[j8r]

Tests are missing

[straight-shoota]

Looks great! Awesome first contribution ❤️

As @j8r said, having a few specs would be nice (see spec/compiler/formatter/formatter_spec.cr).

[j8r]

Can be replaced by:
if formatted_result_expression = after_comment_value.lchop? "=>"

[j8r]

To clarify, both the initial if condition and the line with [2..-1] can be replaced by the above expression.

[fschrfl]

I added some specs and adjusted the code from the first commit based on your suggestions. Thanks for the feedback. Hope, the specs cover everything. I am not very imaginative when it comes to test.

[oprypin]

These specs cover known edge cases but it's as important to test a few basic cases first.

[fschrfl]

What basic cases would you suggest? The two cases that need to be covered are invalid and valid code. Invalid code is covered by the first case, for valid code I could add another basic case like 1 # => 1 + 2 but that is also already covered by the recursion in case two.

[asterite]

What. happens if the comment expression isa method definition with, say, 1 + 2 as the body?

[fschrfl]

That is indeed a problem I did not consider. As it is now, the formatter will put the body and end in separate lines which are not commented out:

1 # => def add12() 1 + 2 end

turns into

1 # => def add12
  1 + 2
end

It would be a good idea, anyway, to only apply formatting to certain kinds of expressions, or better still, to only apply formatting if the formatted string is equal to the result of .inspecting the expression before the comment (see discussion in #7272). If that was implemented, the above problem wouldn't even come up. So before fixing this, it might be a good idea to overthink the whole approach here...

[asterite]

I think it's simpler: try to format it. If you find newlines, then don't use the result.

[asterite]

Specially considering that it's a tool that's combined with the editor. I would find it pretty annoying if the editor starts spitting errors at me because of the way I organize my code.

[straight-shoota]

Yeah maybe the formatter is not the right tool for this. But it would be great to have some formal validation for # => comments and similar.
Maybe that's something for ameba?

[asterite]

If anything, a tool like doctest would be great.

I think having the formatter try to format the value if possible is good enough. Then doctest would actually run it and verify that the results are what you'd expect them to be.

[fschrfl]

Incidentally, is there a reason why def add12 : Int32 1 + 2 end and def add12() 1 + 2 end are valid syntax while def add12 1 + 2 end raises the syntax error "unexpected token: 1"?

[asterite]

Just a lack of thought from us on those details. We should probably copy Ruby or decide what to do, but it's very low priority.

[RX14]

I'd like to wait until #7272 is discussed a bit more.