evaluator: errors with disjunction do not include problem line

[rogpeppe]

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

$ cue version
cue version v0.0.0-20230428121230-80d6ea032057

go version devel go1.21-3ed8a1e629 Tue Mar 28 05:41:44 2023 +0000
      -buildmode exe
       -compiler gc
  DefaultGODEBUG panicnil=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1
             vcs git
    vcs.revision 80d6ea032057b40e405eefab6015e92bbc5cc2a5
        vcs.time 2023-04-28T12:12:30Z
    vcs.modified false

Does this issue reproduce with the latest stable release?

Yes

What did you do?

# Without the disjunction, an error message points to the problematic line.
! exec cue export -e _x ok.cue
stderr '"\^#'

# With the disjunction, there is no error that points to the problematic line.
exec cue export -e _x not_ok.cue
stderr '"\^#'
-- ok.cue --
_x: #Ref & {
	type: "ref"
	ref:  "foo"
}

#Ref: string | {
	type!: "ref"
	ref!: =~ "^#"
}

-- not_ok.cue --
_x: #Object & {
	type: "object"
	property: {
		type: "array"
		items: {
			type: "ref"
			ref:  "foo"
		}
	}
}

#Object: {
	type!: "object"
	property!: #Ref | #Array
}

#Array: {
	type!:        "array"
	items:        #Ref
}

#Ref: string | {
	type!: "ref"

	// This is the problem line, but the error messages don't mention it at all!
	ref!: =~ "^#"
}

What did you expect to see?

A passing test.

What did you see instead?

# Without the disjunction, an error message points to the problematic line. (0.021s)
# With the disjunction, there is no error that points to the problematic line. (0.014s)
> exec cue export -e _x not_ok.cue
[stderr]
_x.property: 2 errors in empty disjunction:
_x.property: conflicting values string and {type:"array",items:{type:"ref",ref:"foo"}} (mismatched types string and struct):
    ./not_ok.cue:3:12
    ./not_ok.cue:22:7
_x.property.type: conflicting values "ref" and "array":
    ./not_ok.cue:1:5
    ./not_ok.cue:4:9
    ./not_ok.cue:14:13
    ./not_ok.cue:23:9
[exit status 1]
FAIL: /tmp/testscript4020124080/x.txtar/script.txtar:6: unexpected command failure

The actual problem here is that there is a conflict between _x.ref and #Ref.ref, but that issue isn't surfaced at all in the errors that are printed. In larger configurations, this can make it very hard to pinpoint the reason for a validation failure.

[mvdan]

I think I found another instance, minified from an example by @mdlayher:

$ cat job.cue
#ValidCells: 1 | 2

requirement: {
	type:  "A"
	cells: #ValidCells
} | {
	type:  "B"
	cells: #ValidCells
} | {
	type:  "C"
	cells: #ValidCells
}

requirement: {
	type:  "C"
	cells: 3
}
$ cue export job.cue
requirement: 2 errors in empty disjunction:
requirement.type: conflicting values "A" and "C":
    ./job.cue:4:9
    ./job.cue:15:9
requirement.type: conflicting values "B" and "C":
    ./job.cue:7:9
    ./job.cue:15:9

type: "C" should have selected the third element in the disjunction, and then we should show the user a single error: the values 1 | 2 and 3 are incompatible.

[mvdan]

Found a workaround like:

$ cat job.cue
#ValidCells: 1 | 2

requirement: {
	type: string
	if type == "A" {
		cells: #ValidCells
	}
	if type == "B" {
		cells: #ValidCells
	}
	if type == "C" {
		cells: #ValidCells
	}
}

requirement: {
	type:  "C"
	cells: 3
}
$ cue export job.cue
requirement.cells: 2 errors in empty disjunction:
requirement.cells: conflicting values 1 and 3:
    ./job.cue:1:14
    ./job.cue:11:2
    ./job.cue:12:10
    ./job.cue:18:9
requirement.cells: conflicting values 2 and 3:
    ./job.cue:1:18
    ./job.cue:11:2
    ./job.cue:12:10
    ./job.cue:18:9

Avoiding the disjunction means that we force the evaluator to go into the "C" path, so the errors are a little bit better.

[myitcv]

Adding triage to work out whether this is a regression or not.

[rogpeppe]

This doesn't seem to be a regression from v0.4.3 at any rate.

Here's a similar example (avoiding the required fields) that demonstrates the same problem in v0.4.3. It's possible that the issue wasn't demonstrated in versions prior to that, but the implementation was different enough that it's probably not worth doing that experiment.

# Without the disjunction, an error message points to the problematic line.
! exec cue export -e _x ok.cue
stderr '"\^#'

# With the disjunction, there is no error that points to the problematic line.
! exec cue export -e _x not_ok.cue
stderr '"\^#'
-- ok.cue --
_x: #Ref & {
	type: "ref"
	ref:  "foo"
}

#Ref: string | {
	type: "ref"
	ref: =~ "^#"
}

-- not_ok.cue --
_x: #Object & {
	type: "object"
	property: {
		type: "array"
		items: {
			type: "ref"
			ref:  "foo"
		}
	}
}

#Object: {
	type: "object"
	property: #Ref | #Array
}

#Array: {
	type:        "array"
	items:        #Ref
}

#Ref: string | {
	type: "ref"

	// This is the problem line, but the error messages don't mention it at all!
	ref: =~ "^#"
}

[EliFeinberg]

Working on fixing this issue! Would love feedback on proposal below
https://docs.google.com/document/d/1IlXNW32-tUET56mjm5htF7LLfDIsbiC4zk78cWGvfrA/edit