Doesn't parse valid Nix edge-cases

[puckipedia]

let b = a: a; "or" = 5; in [b or] fails to be properly parsed, and instead generates a partial NODE_OR_DEFAULT and errors.

This seems to also influence other bits, e.g. [b or b] parses as a valid NODE_OR_DEFAULT, while it is actually parsed as [(b or) b] by Nix.

[jD91mZM2]

Ah, I see. So or is really a function (whose name is suffixed) that takes a default value as argument?

I assume (5 +) 3 doesn't work though, as it does in Haskell? Just checking - I am on phone currently

I see what you mean, I need to make or able to be overwritten somehow. That's a problem, since rnix knows nothing about which variables are in scope. Oof

[jD91mZM2]

No wait wtf, it only works when it's or.

let
  inc = n: n + 1;

  number = 3;
  or = 3;
in
{
  inc_number = [ inc number ]; # [ <LAMBDA> 3 ]
  inc_or = [ inc or ]; # [ 4 ]
}

pls send help

can we like, uh, just ignore this and pretend it's a bug in nix? i am confused

[zimbatm]

in nixpkgs/lib/default.nix we also encounter this issue: https://github.com/NixOS/nixpkgs/blob/810d22fb35287e14125470e3b917b90488ae5ed5/lib/default.nix#L67

Minimal repro:

let
  inherit (builtins) a b c d or e;
in
null

[Ma27]

Self-assigning here as this is something we should tackle at some point. Please note that getting out a new rnix-lsp release soon has a higher priority for me and I only have a fairly limited time budget for maintaining rnix* :)

[oppiliappan]

@Ma27 I'd be happy to help work on this crate, or atleast close off loose ends, I am using it for a couple of projects. Is there a matrix/irc channel where the maintainers coordinate?

[Ma27]

We usually use #rnix-lsp:matrix.org, but since rnix-lsp and rnix-parser are both maintained by the same folks currently (primarily Aaron and me), it's perfectly fine to use it :)

[Ma27]

I'd consider this to be a tracking issue now for 1.0 where we should try to be equivalent to Nix's parser. That said, minor things can be done in the next release I'd plan, 0.10.

[aaronjanse]

can we like, uh, just ignore this and pretend it's a bug in nix? i am confused

Please. I'm strongly in favor of changing this in the official nix parser. Of course, if upstream refuses to make the change, then we should also implement the bug feature to match the reference implementation

[L-as]

can we like, uh, just ignore this and pretend it's a bug in nix? i am confused

Please. I'm strongly in favor of changing this in the official nix parser. Of course, if upstream refuses to make the change, then we should also implement the bug feature to match the reference implementation

Changing the language backwards incompatibly is a hard no-go IMO. Doesn't matter how stupid the design is. You're going to break supposedly hermetic flakes. If you want to fix this, you should propose a mechanism for introducing new versions of the language à la Rust editions or something along those lines.

[zimbatm]

The best we can do is make sure the bug is documented, here and upstream. And potentially emit a warning whenever it's encountered.