Fix language annotations inside lists on function arguments

[dyegoaurelio]

I noticed this while working on #353

list rendering code inside function arguments has special handling and was not considering language annotations.

This ensures the language annotations are formatted as intended on this case.

Before:

  runScripts = (
    lib.mkSomething
      [
        /* bash */
        ''
          echo "Script A"
        ''
      ]
      [
        /* python */
        ''
          print("Script B")
        ''
        /* ruby */
        "puts 'Script C'"
      ]
  );

Now:

  runScripts = (
    lib.mkSomething
      [
        /* bash */ ''
          echo "Script A"
        ''
      ]
      [
        /* python */ ''
          print("Script B")
        ''
        /* ruby */ "puts 'Script C'"
      ]
  );

[github-actions]

Nixpkgs diff

[piegamesde]

Honestly, this feels like a bandaid. If the original implementation of the feature requires such fixes, I'd suggest revising its fundamental approach rather than going through all edge cases of the code base one by one over the years.

[dyegoaurelio]

Honestly, this feels like a bandaid. If the original implementation of the feature requires such fixes, I'd suggest revising its fundamental approach rather than going through all edge cases of the code base one by one over the years.

It does, but I'm not sure how we could refactor the implementation to avoid edge cases like this one.

The formatting for the language annotation comment is different from the formatting for other comments on list entries.

So I added explicit handling for it on the list item rendering code

 -- For lists, attribute sets and let bindings
 prettyItems :: (Pretty a) => Items a -> Doc
-prettyItems (Items items) = sepBy hardline items
+prettyItems (Items items) = go items
+  where
+    go [] = mempty
+    go [item] = pretty item
+    -- Special case: language annotation comment followed by string item
+    go (Comments [LanguageAnnotation lang] : Item stringItem : rest) =
+      pretty (LanguageAnnotation lang)
+        <> hardspace
+        <> group stringItem
+        <> if null rest then mempty else hardline <> go rest
+    go (item : rest) =
+      pretty item <> if null rest then mempty else hardline <> go rest

I just wasn't aware that there was another code path that was formatting lists without calling this function.

Maybe a nice approach here would be to make the list rendering code a bit more DRY, by creating a function that's called by both absorbInner and prettyTerm (List paropen@Ann{trailComment = post} items parclose)

[jfly]

Reviewed as a team. LGTM!

[infinisil]

LGTM!