Support let blocks in nickel

[jneem]

Support let blocks in nickel

Description

Nickel's master branch now has support for "let blocks", where multiple comma-separated bindings can be placed between the "let" and the "in", like

let
a = 1,
b = 2,
in
a + b

This PR introduces support for formatting let blocks, which it handles differently from single let bindings in two ways: the first binding is allowed to go on its own line, and new lines are allowed after each comma.

It would also be possible to indent the bindings, like

let
  a = 1,
  b = 2,
in
a + b

but it feels a bit strange to me to indent the bindings and not the term after "in".

Checklist

Checklist before merging:

• CHANGELOG.md updated
• README.md up-to-date

[yannham]

I vote for the second solution, which is for example what Nix formatters do (and Dhall, I think) and also is more in-line with the way we currently format multi-line let-bindings.

The rationale is that bindings are "one level deeper", but the body is the continuation of the program, and can be huge. And you often chain let-bindings a lot, so you don't want to end up with something like:

let
  a = 1,
  b = 2,
in
  let
    c = a,
    d = b,
  in
    let ...

[jneem]

Ok, I went for the indented bindings.

Btw, the update-wasm-grammars.sh script doesn't seem to work anymore, since nickel (and many other grammars) are no longer in the Cargo.lock. Maybe it should get the revisions from topiary-config/languages.ncl instead?

[Xophmeister]

LGTM, although there are no test cases (see topiary-cli/tests/samples/{input,expected}/nickel.ncl)

[jneem]

Good call on the testing -- I've bumped into some idempotency issues, so will need to revisit this tomorrow...

[jneem]

Ok, it turned out my issues were caused by the comma in a let block inside a container being misinterpreted as a comma separating two items in the container. I fixed this by changing the container comma rule to only track commas after a container element, and not at some arbitrary position in the container.