In reply to @balsoft:balsoft.ru

E.g. two consequtive runs of nix-store --realise on the same derivation:

error: 1 dependencies of derivation '/nix/store/<...>-nixos-system-foo.drv' failed to build

And second one:

error: builder for '/nix/store/<...>-nginx.conf.drv' failed with exit code 1;
       last 10 log lines:
       >     }
       > }
       >
       > ==================== Summary ===================
       > Total issues:
       >     Unspecified: 0
       >     Low: 0
       >     Medium: 1
       >     High: 0
       >
       For full logs, run 'nix log /nix/store/<...>-nginx.conf.drv'.
error: 1 dependencies of derivation '/nix/store/<...>-unit-nginx.service.drv' failed to build
error: 1 dependencies of derivation '/nix/store/<...>-system-units.drv' failed to build
error: 1 dependencies of derivation '/nix/store/<...>-etc.drv' failed to build
error: 1 dependencies of derivation '/nix/store/<...>-nixos-system-foo.drv' failed to build

In reply to @andi:kack.it
Before diving into doing the change I had a thought yesterday while looking at related code: Any reason we don't implement Expr{Sub,Add,...} like we do for ExprNotOp etc? In the case of subtraction it could get rid of about 30k Symbol table looks, a few thousand new objects (while building a NixOS test). And execution wouldn't probably do a few less function calls. That would probably break overriding substraction by providing a __sub (or whatever) function in the current scope (if that even works right now).

In reply to @niksnut:matrix.org
No, I think the reason it's implemented that way is because builtins.sub etc. already existed

Would you see any downside to adding those implementations? I could have a go on the in one of the coming evenings.

I don't think that it will improve performance by a lot but I also haven't measured the time spent in those functions. I was just surprised that IIRC the sub primop was the most used one (by a few 10k) when I did eval a NixOS VM test.

In reply to @niksnut:matrix.org
Sure, I can do a release

In reply to @tomberek:matrix.org
musl issue is related to: 4993174