Unexpected unsafeGetAttrPos output depending on attrset merge order

[numinit]

Describe the bug

Depending on the relative ordering of a call to unsafeGetAttrPos to an attrset merge on the declaring attrset, the output of unsafeGetAttrPos may be different.

Tested on:

• nix (Nix) 2.24.13
• nix (Lix, like Nix) 2.91.1

Steps To Reproduce

Run https://gist.github.com/numinit/60c69b6873812c5e51c307f19cbb104b on nixpkgs master.

Expected behavior

The attribute position is unchanged regardless of where the call to unsafeGetAttrPos is (since it's a variable in the scope, after all), and refers to the original position. Right now it looks like the position is mutated!

The critical line is // attrs.meta or { }. If the call to unsafeGetAttrPos is moved afterwards, it misbehaves and returns the position in the current file, instead of the position in the original definition of attrs.

Metadata

nix-env (Nix) 2.24.13

Additional context

Checklist

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

---

Add 👍 to issues you find important.

[numinit]

Other things I've tried:

• Toy example: not reproducible. Something about the complexity of nixpkgs is involved.
• GC_DONT_GC=1: still reproducible, may rule out GC.