internal/core/eval: unresolved embedded scalar disjunction influences unrelated definition

[myitcv]

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

$ cue version
cue version +0070bb10 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

-- foo.cue --
package foo

#SomeBaseType: {
 "a" | "b"
 #AUTO: "z"
}

V1: ("x" | "y") | *"z"
V2: ("x" | "y") | *#SomeBaseType.#AUTO
-- foo2.cue --
package foo

V3: #SomeBaseType.#AUTO

If we do:

$ cue export .

we get the following error:

V3: unresolved disjunction "a" | "b" (type string):
    ./foo2.cue:3:5

This seems wrong, because whilst #SomeBaseType.#AUTO does reference #SomeBaseType, the fact the disjunction is unresolved should not matter, because we are addressing #AUTO.

If we then do:

$ cue eval foo.cue

(i.e. ignoring V3) then we get:

#SomeBaseType: {
    "a"
    #AUTO: "z"
} | {
    "b"
    #AUTO: "z"
}
V1: "z"
V2: "x" | "y"

Here we would expect V2 to be "z", but because of the error described above the default gets eliminated, hence we are left with "x" | "y"; so not as expected, but at least understandable in the context of the previous observation.

If we then do:

$ cue export foo.cue

we get no output, no error message, and a non-zero exit code. As stated above we would expect V2 to be "z", but given the current output from cue eval foo.cue we would, given the current implementation, expect an error message like:

V2: unresolved disjunction "a" | "b" (type string)

But this final scenario is effectively two errors stacked on top of each other, so it's not clear that our expectation is reasonable here.

What did you expect to see?

As above.

What did you see instead?

As above.

cc @dubo-dubon-duponey

[mpvl]

CUE makes no distinction between embedded structs or embedded scalars. This behavior is especially useful if the embedded values are references.

[cueckoo]

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

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