Successfully parsing expressions that standard Nix doesn't parse

[infinisil]

As discussed on Discourse, opening an issue to discuss what to do about expressions that standard Nix throws an error for, but nixfmt doesn't mind.

The cases I found are:

{
  a = {
    a = 0;
    a = 0;
  };

  b = { x }@x: null;

  c = { x, x }: null;

  d = doesn't-exist;

  e = {
    ${"x"} = 10;
    x = 10;
  };
}

[Lucus16]

Reporting errors about duplicate assignments is relatively hard in the current code base, because location information isn't stored, it's only available during parsing. This feature won't really become valuable until nixfmt is usable enough that people want to replace their syntax checking plugins with it. We can consider this once nixfmt reaches fairly stable formatting output and it becomes somewhat popular to use.

[Lucus16]

After thinking about it, a, b and c can be detected easily if we accept that the error specifies the surrounding set/setparameter as location.

[Lucus16]

e can also be detected if we implement simplification of redundant instructions. I don't think d should be a parsing error.

[piegamesde]

I don't think nixfmt should reject any of these, as long as they are syntactically correct. (I'm unsure about d tough.) It is totally acceptable to correctly format a syntactically correct file, even if it does not evaluate in Nix