cue: cue: optional fields cannot be referenced in for loops of optional fields
What version of CUE are you using (cue version)?
$ cue version 0.4.3
Does this issue reproduce with the latest release?
yes
What did you do?
parameter: {
optioanlArr?: [...{
name: string
data?: string
}]
}
outputs: {
for v in parameter.optionalArr if v.data != _|_ {
name: v.name
}
}
What did you expect to see?
This is also the result in cue 0.2.2:
outputs: {
for v in parameter.optionalArr if false {
name: v.name
}
}
What did you see instead?
outputs: {
for v in parameter.optionalArr if v.data != _|_ // explicit error (_|_ literal) in source
{
name: v.name
}
}
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 35 (21 by maintainers)
I’ve been looking into this a bit more. Here’s a smaller version of the example which I think represents the problem concisely:
A
cue exporton this succeeds OK on v0.2.2 but fails with “cannot reference optional field: p” on v0.4.3.Note that without the disjunction (just using
a: [for k in p {k}]) it fails on both versions, so the key here seems to be the disjunction.By contrast, this code works fine on both versions of CUE:
so it’s clear to me that a reference to an optional value evaluates to bottom, as do expressions containing such a reference, and according to the spec:
AFAICS there should not be a qualitative difference between a comprehension involving a reference to an optional value and any other expression involving an optional value, so at the moment I see this as a straightforward bug in the latest version of CUE.
@FogDong I believe Roger is just pointing out that the bug appears in one case but not the other.
So, to be a bit clearer for folks following along, fixing the bug in v0.4.3 will fix some but not all of the issues that are being seen. As an example, this code has several list comprehensions that will be fixed, but some struct comprehensions (e.g. this) which won’t and will need the CUE to be fixed.
Great.
https://pkg.go.dev/cuelang.org/go/tools/fix#Instances will likely be that; but will wait for @rogpeppe’s analysis to confirm.
Thanks, @FogDong. For anyone following along, here is a standalone reproducer:
@FogDong’s expectation is that this test should pass, but it fails with:
Looking into this now.
We are close to committing a first version of both the reworked cycle detection algorithm and comprehension rewrite.
I’ll keep this on the list of things to validate in rolling this out.