Remove or clean up builtins.toXML

[numinit]

Is your feature request related to a problem?

toXML has some surprises:

• let x = [ x ]; in builtins.toXML x blows the stack and crashes the interpreter fixed now 👌
• has "unique" formatting of floats that bypasses the normal toString logic, limiting the effectiveness of libexpr: unify toString for nan and inf #15704
• lets you introspect the function args of lambdas in pure eval: functionArg = fn: if builtins.isFunction fn then let m = builtins.match ''^.*<varpat[[:space:]]+name="([^"]+)"[[:space:]]+/>.*$'' (builtins.toXML fn); in if m == null then null else builtins.head m else null
• let you get the name of @args variables, as well as the ellipsis flag for formal parameterized functions, which builtins.functionArgs cannot do (so we have created a weird API around that as well)
• I'm not sure who actually uses it considering we have toJSON. I found one single usage in nixpkgs, in GRUB. That's rather unfortunate, but also could probably be adapted to not rely on it.
  • It lets you introspect Nix expressions, which may be useful, but feels more like a debug tool than something that we should be using.
  • As an example, noogle uses a C plugin for docs.

Proposed solution

Remove it completely. Some of this functionality seems like it should be used in plugins rather than being exposed to the evaluator.

Alternative solutions

Keep it and fix it, but add an eval warning for using it. Maybe even remove some of the things it can do to just allow serializing flat data, possibly so GRUB configs still work in old versions of nixpkgs.

Additional context

Checklist

• checked latest Nix manual (source)
• checked open feature issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[grahamc]

It is (tragically) in use, but I would be supportive of moving it behind a deprecated features flag and setting a deletion timeline

[xokdvium]

This unbounded stack overflow has been fixed in 2.34:

let x = [ x ]; in builtins.toXML x
error:
       … while calling the 'toXML' builtin
         at «string»:1:19:
            1| let x = [ x ]; in builtins.toXML x
             |                   ^

       error: stack overflow; max-call-depth exceeded

[xokdvium]

lets you introspect the function args of lambdas in pure eval: functionArg = fn: if builtins.isFunction fn then let m = builtins.match ''^.<varpat[[:space:]]+name="([^"]+)"[[:space:]]+/>.$'' (builtins.toXML fn); in if m == null then null else builtins.head m else null
let you get the name of @Args variables, as well as the ellipsis flag for formal parameterized functions, which builtins.functionArgs cannot do (so we have created a weird API around that as well)

Tbh these 2 points seem more of a motivation for a better functionArgs. Not being able to check presence of arguments to primops is also annoying and makes backwards compatible changes to add new arguments to primops (the ones with formal arguments) basically impossible. If anything, functionArgs is the outlier here - not toXML.

[xokdvium]

But also, this seems to be a pretty strong argument that nix is basically never going to have a chance of having alpha equivalence...

[numinit]

Yeah... any way that isn't "we have to parse XML through regex or WASM to find whether we have an ellipsis in a set of formal function arguments" sounds great to me. Guess it depends on what should be allowed to leak through into the eval context, the leakage of floats is an example of "weird" but so is functions because there's no analog elsewhere.

For lambdas, yeah, it would break alpha equivalence if they ended up being load bearing...