cmd/cue: trim bug when using disjunction of embeded definitions?

[joulaud]

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

$ cue version
cue version 0.4.0 linux/amd64

Does this issue reproduce with the latest release?

What did you do?

$ cat <<'EOF' >x.cue
#DefA: A: "a"
#DefB: B: "b"

First: {
        #DefA | #DefB
        C: "c"
}

First: {
        B: "b"
        C: "c"
}
EOF


$ cue trim x.cue
  {
      #DefA: {
        A: "a"
      }
      #DefB: {
        B: "b"
      }
-     First: {
-       B: "b"
-       C: "c"
-     }
+     First: {
+       C: "c"
+       A: "a"
+     } | {
+       C: "c"
+       B: "b"
+     }
  }
Aborting trim, output differs after trimming. This is a bug! Use -i to force trim.
You can file a bug here: https://github.com/cuelang/cue/issues/new?assignees=&labels=NeedsInvestigation&template=bug_report.md&title=

What did you expect to see?

No error, and trimming of line 11 C: "c"

What did you see instead?

Bug detection by cue trim as described above.

[mpvl]

The faulty trim is caused by the removal of B: "b" in the second First. This is related to another outstanding trim bug.

Note however, that, with the current interpretation of trim, C: "c" cannot be removed, as it would not know which of the two instances of C: "c" should be removed as one does not "dominate" the other.

[mpvl]

To be more precise on what is going on: evaluation eliminates one of the disjunctions. Trim proceeds with the evaluated value as if it weren't evaluated from a disjunction. It then removes the very field that was used to disambiguate the disjunction. After this removal, the disjunction no longer disambiguates.

[myitcv]

Dropping the now meaningless v0.4.x milestone. We have relabelled this from trim to roadmap/trim to indicate that a fix for this issue (and indeed all trim issues) requires a more substantial piece of work.