eval: nested struct unification in list comprehension guard differs from let binding

[myitcv]

What version of CUE are you using?

cue version v0.16.0-rc.1.0.20260303225502-310f61c32cf1

What did you do?

A deeply nested struct unification expression evaluates differently when used inline as a list comprehension guard vs when bound to a field and then referenced in the guard.

Minimal reproducer:

exec cue export x.cue
cmp stdout stdout.golden

-- x.cue --
_nonzero: {
	#arg?: _
	out: [if #arg != _|_ {
		[
			if (#arg & bool) != _|_ {#arg},
			false,
		][0]
	}, false][0]
}

// Bound to a field: evaluates correctly (true)
cond: (_nonzero & {#arg: [if (_nonzero & {#arg: !((_nonzero & {#arg: false}).out)}).out {
	!((_nonzero & {#arg: false}).out)
}, false][0]}).out

// Using the binding: produces ["yes"]
outputA: [
	if cond {"yes"},
]

// Inline (same expression): produces [] — should produce ["yes"]
outputB: [
	if (_nonzero & {#arg: [if (_nonzero & {#arg: !((_nonzero & {#arg: false}).out)}).out {
		!((_nonzero & {#arg: false}).out)
	}, false][0]}).out {"yes"},
]
-- stdout.golden --
{
    "cond": true,
    "outputA": [
        "yes"
    ],
    "outputB": [
        "yes"
    ]
}

What did you expect to see?

Passing test.

Both outputA and outputB should produce ["yes"] since the guard expression is the same (just inline vs bound).

What did you see instead?

[stdout]
{
    "cond": true,
    "outputA": [
        "yes"
    ],
    "outputB": []
}
> cmp stdout stdout.golden
diff stdout stdout.golden
--- stdout
+++ stdout.golden
@@ -3,5 +3,7 @@
     "outputA": [
         "yes"
     ],
-    "outputB": []
+    "outputB": [
+        "yes"
+    ]
 }

FAIL: repro.txtar:2: stdout and stdout.golden differ

outputB is empty — the inline guard evaluates to false (or incomplete) even though the identical expression bound to cond evaluates to true.

Context

This was discovered while working on helm2cue (cue-exp/helm2cue#120), where the converter generates deeply nested _nonzero truthiness checks. The workaround is to bind the condition to a let/field before using it as a guard, but programmatic CUE generation naturally produces the inline form.

[myitcv]

Closing - this was posted before I could catch claude :(

[myitcv]

This does indeed look like a real bug. Updated the description with a better reproducer.

[myitcv]

https://cue.gerrithub.io/c/cue-lang/cue/+/1233265 might be useful in solving this.

[mvdan]

Following the smaller reproducer from your CL above, I've further reduced it to:

exec cue export in.cue

-- in.cue --
_truthy: {
	_in: _
	_out: [[
		if (_in & true) {_in},
		false,
	][0]][0]
}

innerTrue: (_truthy & {_in: true})._out
outerTrue: (_truthy & {_in: (_truthy & {_in: innerTrue})._out})._out
outerTrueCond: [
	if (_truthy & {_in: (_truthy & {_in: innerTrue})._out})._out {true},
]

as of d8a8c79:

> exec cue export in.cue
[stdout]
{
    "innerTrue": true,
    "outerTrue": true,
    "outerTrueCond": []
}

[mvdan]

It's also entirely possible that this is related to Marcel's ongoing comprehensions rework, given that it is the introduction of a comprehension which breaks this.

[mvdan]

Claude came up with the fix below, which does work for this example:

diff --git internal/core/adt/cycle.go internal/core/adt/cycle.go
index 28a6ca70c..b707d8e29 100644
--- internal/core/adt/cycle.go
+++ internal/core/adt/cycle.go
@@ -473,6 +473,15 @@ func (n *nodeContext) detectCycle(arc *Vertex, env *Environment, x Resolver, ci
 				return ci, true
 			}
 
+			// For dynamic/inline vertices (created by newInlineVertex for
+			// expressions like _f & {...}), a matching arc from a different
+			// node means the same definition is referenced in a nested
+			// inline evaluation. This is not a cycle — genuine cycles
+			// through inline vertices are caught by hasAncestor above.
+			if n.node.IsDynamic {
+				continue
+			}
+
 			// If there are still any non-cyclic conjuncts, and if this conjunct
 			// is optional, we allow this to continue one more cycle.
 			if ci.CycleType == IsOptional && n.hasNonCyclic {

Sadly, it makes a bunch of existing tests no longer detect as cycles, and loop forever. In any case, the issue here seems to be related to cycle detection alongside comprehensions.