eval: use of list.Contains fails on list derived from comprehension

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version +2c86835c linux/amd64

Does this issue reproduce with the latest release?

Yes. Bisected down to 2c86835

What did you do?

exec cue eval working.cue
exec cue eval broken.cue
-- working.cue --
package preguide

import (
	"list"
)

#Guide: {
	Steps: #Command & {
		Terminal: *Terminals[0] | string
	}
	Terminals: [...string]
	ok: true & list.Contains(Terminals, Steps.Terminal)
}

#Command: {
	Terminal: string
}

#Terminal: {
}

g: #Guide & {
	Terminals: ["term1"]
	Steps: #Command
}
-- broken.cue --
package preguide

import (
	"list"
)

#Guide: {
	Steps: #Command & {
		Terminal: *TerminalNames[0] | string
	}
	Terminals: [...string]
	TerminalNames: [ for k in Terminals {k}]
	ok: true & list.Contains(TerminalNames, Steps.Terminal)
}

#Command: {
	Terminal: string
}

#Terminal: {
}

g: #Guide & {
	Terminals: ["term1"]
	Steps: #Command
}

What did you expect to see?

Passing test.

What did you see instead?

> exec cue eval
[stderr]
g.ok: conflicting values false and true:
    ./main.cue:13:6
    ./main.cue:13:13
    ./main.cue:23:4

The difference between working.cue and broken.cue is enough to cause this to break, despite the fact that both are string lists of the same value:

--- working.cue 2021-02-20 05:59:11.159756947 +0000
+++ broken.cue  2021-02-20 05:59:11.159756947 +0000
@@ -6,10 +6,11 @@

 #Guide: {
        Steps: #Command & {
-               Terminal: *Terminals[0] | string
+               Terminal: *TerminalNames[0] | string
        }
        Terminals: [...string]
-       ok: true & list.Contains(Terminals, Steps.Terminal)
+       TerminalNames: [ for k in Terminals {k}]
+       ok: true & list.Contains(TerminalNames, Steps.Terminal)
 }

[myitcv]

FYI - this is not critical to the PWG project. Just noticed in passing (we are in the process of refactoring our schema and can therefore workaround this)

[cueckoo]

This issue has been migrated to cue-lang/cue#784.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.