Separate new-syntax contracts with linebreaks

[0xEAB]

Separate new-syntax contracts with linebreaks. Implements #331 in a mostly unintrusive way (as far as I can tell).

[deadalnix]

The sensible way to do this would probably to make this a list, but lists are nasty. Manually adding the line break doesn't really cut it, because when you start breaking, you want to either break the initial contract or to align the break on the initial contract.

Plus, this can be mixed up with a template constraints, attribute and qualifier, etc... This is not something I think we should add special case for, because special cases will call for special cases.

The way to go clearly is to use the list formatting, but I'm not sure how easy or hard this is. I suspect it might be hard. Also on a side note, I plan on revamping the way list work int he formatter, because in addition to being nasty, they have some pathological performance characteristics in extreme cases (like say, an array literal with thousands of elements in it). the root of the issue is that the formatter is actually completely unaware of lists;, they are implemented via spans, so it has to try all kind of combinations of break that the span is going to subsequently shut down.

[0xEAB]

This is not something I think we should add special case for

From what I’ve seen while implementing this, we’ll probably need a more sophisticated approach then. Without special-casing this to “multiple new-syntax contracts” one’d end up with very intrusive reformatting.

[maxhaton]

The sensible way to do this would probably to make this a list, but lists are nasty. Manually adding the line break doesn't really cut it, because when you start breaking, you want to either break the initial contract or to align the break on the initial contract.

Plus, this can be mixed up with a template constraints, attribute and qualifier, etc... This is not something I think we should add special case for, because special cases will call for special cases.

The way to go clearly is to use the list formatting, but I'm not sure how easy or hard this is. I suspect it might be hard. Also on a side note, I plan on revamping the way list work int he formatter, because in addition to being nasty, they have some pathological performance characteristics in extreme cases (like say, an array literal with thousands of elements in it). the root of the issue is that the formatter is actually completely unaware of lists;, they are implemented via spans, so it has to try all kind of combinations of break that the span is going to subsequently shut down.

This would be good dogfood for improving that kind of feature. This PR is quite ugly both in terms of aesthetics and upsetting grug e.g. a counter inside the parser is not great.

For the simple cases of lists I think you might be able to get a very long way with a good heuristic as long as you can prepare the head and tail right e.g. if you can get right rhythm going then I think you could lay out the bulk of the list (e.g. consider the case of lots of an array of struct initializers) geometrically rather than by cost.