Formatter: five cases where comments and doc comments are placed wrongly #9107

Found by a bug hunt over the 16 commits from eb087382 to cd641cbc.

All five are stable when formatted again. The fourth changes the AST, and the others change only the layout.

1. A doc comment on a single hugged parameter is printed with a line break and no indent:
   let f = (/** r */ {x, y}) => x prints as let f = (/** r */ followed by {x, y}) => x at column 0. The same happens for [a], (a, b) and (). parameters_should_hug checks the parameter's attrs but not pat.ppat_attributes, where the doc comment is stored. This input is accepted since Parse a doc comment before a function parameter #9055.
2. A trailing line comment after a parenthesized switch/if operand moves into the block, followed by a blank line:
   switch (x) // c1 then { | 1 => 2 | _ => 3 } prints as switch x {, then // c1, a blank line and | 1 => 2. Without the parentheses (Keep a line comment in a block construct's operand in the operand #9061) the comment stays with the operand.
3. A comment before a list tail spread moves after the dots:
   list{1, /* c */ ...xs} prints as list{1, .../* c */ xs}. Arrays keep it in place.
4. Doc comments are printed before an attribute that precedes them, which changes the attribute order in the AST:
   type u = /** d1 */ @a /** d2 */ {x: int} prints /** d1 */, /** d2 */, then @a type u = {x: int}.
5. A file that contains only a line comment gets an extra trailing newline: // c\n formats as // c\n\n.

Cases 2, 3 and 5 reproduce at b123b7c3. That revision rejects the inputs of 1 and 4.

🤖 Generated with Claude Code