Comments can affect the formatting behaviour in unintentional ways

[garyb]

module Main where

changeDialog = do
  -- oh noes
  { x } ← H.get
  pure unit

The presence of the comment reformats the record destructuring like this:

module Main where

changeDialog = do
  -- oh noes
  { x
  } ← H.get
  pure unit

[natefaubion]

This is a problem with delimiters and leading comments in general. The formatter doesn't look at spans, but it does bubble up a "multiline" flag. Essentially, printing the leading token makes it mark it as "multiline" because of the leading comment, and it skips the speculative layout at that point and commits to the multiline variation.

[natefaubion]

To be more accurate, this crops up when a semantic element gets flexGrouped for dynamic layout behavior, but has leading line comments. At the point it gets grouped, the comments have already been baked into the FormatDoc, and so it opts out of dynamic layout behavior since it already knows it's broken up over multiple lines. The problem is we want the flexGroup to apply to the semantic element, and not the comment elements. The "correct" solution is probably to buffer comments in FormatDoc, and only bake them in when joining two FormatDocs. There's potentially a quick fix though to just reassociate this grouping for the common delimiters (formatList). There may be other cases that fit this bill, but I'm pretty confident that 90% of the time this might crop up would be with the primary list/delimiter formatter.

For example, applications are fine:

wat =
  -- ok
  a b c

[natefaubion]

I've put in the quick fix in 400d99e. This should fix the issue with delimiters for now, but there may be other cases that require the general fix. I'll leave this open in case other issues like it pop up.

[natefaubion]

Another case of this is comments on branches in a multi-case.

case _, _ of
  -- A comment
  foo, bar -> ...

Will get turned into

case _, _ of
  -- A comment
  foo,
  bar -> ...

[andys8]

I'm seeing a similar case.

-- ids
data NodeId'
type NodeId = Id NodeId'

data LinkId'
type LinkId = Id LinkId'

With the --ids comment, purs-tidy will split the first two lines and separate them with a newline. This won't happen for the second id type because there is no comment

-- ids
data NodeId'

type NodeId = Id NodeId'

data LinkId'
type LinkId = Id LinkId'

[natefaubion]

@andys8 Thanks! That's a good example, and yeah, it's caused by the same root issue. I think both that and the binder issue can be corrected without rewriting FormatDoc. I'll probably go down that route as long as possible 😭.

[natefaubion]

The proper fix may be a lot easier now though since I rewrote the Hang module.

[natefaubion]

Fixed in 0.5.3