feat: support chained member check fallbacks (a ? b ? c)

[dyegoaurelio]

Allow the ? operator to chain: a member check can now be followed by further ? selector.path fallbacks, e.g. {} ? foo ? bar ? null. Previously the operator accepted a single selector path and a chain was a parse error.

Note that this syntax is never useful in practice: it parses left-associatively as (a ? b) ? c, so the first check yields a boolean and each further check tests an attribute on that boolean, making any chain of two or more ? evaluate to constant false. It is valid Nix syntax nonetheless, so the formatter handles it for correctness.

MemberCheck now carries a non-empty list of (question mark, selector path) pairs instead of a single pair. A chain stays on one line when it fits; otherwise it breaks before every question mark, indented one level past the subject:

  aaaaaaaaaaaaaaaaaaaaaaaaaa
    ? bbbbbbbbbbbbbbbbbb
    ? cccccccccccccccccc

Like other operators, a comment trailing a question mark is moved onto its own line above it, keeping the question mark attached to its selector path.

closes #359

[github-actions]

Nixpkgs diff

[dyegoaurelio]

the nixpkgs diff was an improvement IMO

diff --git a/nixos/modules/hardware/facter/camera/ipu6.nix b/nixos/modules/hardware/facter/camera/ipu6.nix
index 5319d8bf3d49f..799c221888245 100644
--- a/nixos/modules/hardware/facter/camera/ipu6.nix
+++ b/nixos/modules/hardware/facter/camera/ipu6.nix
@@ -66,7 +66,7 @@ let
       in
       bus_type.name == "PCI"
       && devices
-      ? "${vendorHex}:${deviceHex}:${subVendorHex}:${subDeviceHex}/${baseClassHex}-${subClassHex}-${revisionHex}"
+        ? "${vendorHex}:${deviceHex}:${subVendorHex}:${subDeviceHex}/${baseClassHex}-${subClassHex}-${revisionHex}"
     );
 in
 {

the indentation also applies on ? operators without a further chain

[jfly]

Thanks! I haven't read the haskell diff closely (would prefer to do that in person, but it's totally OK if you get a shipit from someone else before then). The test cases look good, though.

I agree the nixpkgs diff is nice.

[MattSturgeon]

SGTM, but I think we should be careful about calling ? chains a "fallback", as that is not what they represent even if that may be what users intended.

[MattSturgeon]

Suggested change

	# Chained fallbacks as default values
	# Chained presence checks as default values

Terminology nit: to me, a fallback is what the or operator represents. The ? operator does not really have a fallback concept, and when chained it is just checking that the first Boolean contains an attribute.

Therefore I think we can avoid confusion by talking about attr-presence instead of fallbacks.