"field ... not allowed" error

[cueckoo]

Originally opened by @powerduncan in cuelang/cue#481

I've been struggling with a confusing "field ... not allowed" error. I think I've gotten it down to a minimal(-ish) reproduction, in that just about any change results in a successful evaluation, but I can't figure out why:

$ cat error.cue
out: {
        instance
}
instance: #Type & {
        alpha: bravo: charlie: true
}
#Type: #Root & {
        alpha?: bravo?: charlie?: bool
}
#Root: { ... }

$ cue eval error.cue
out.alpha.bravo: field `charlie` not allowed:
    ./error.cue:5:9
    ./error.cue:5:16
    ./error.cue:8:10
    ./error.cue:8:18

$ cue version
cue version 0.3.0-alpha1 darwin/amd64

Changes from this state that result in completely unexplained success:

• Removing out: { instance }
• Changing out to simply out: instance (rather than using an embedding)
• Removing any of alpha, bravo, and charlie (overkill, sure, but just to be safe, I checked the removal of each independently, keeping the rest of the sequence intact: alpha?: bravo?: bool, alpha?: charlie?: bool, etc.)

I have identified two other changes that also result in a successful evaluation. I understand these both to eliminate the effect of the "closed-ness" of #Root, but that doesn't quite make sense to me as I thought that ... was supposed to keep the struct open.

• Changing #Root to Root
• Embedding #Root, instead of unifying with it (i.e., #Type: { #Root, alpha?: ... })

Interestingly, adding delta to the chain (alpha?: bravo?: charlie?: delta?: bool, etc.), changes the error slightly:

$ cue eval error.cue
out.alpha.bravo: field `charlie` not allowed:
    ./error.cue:5:9
    ./error.cue:5:16
    ./error.cue:8:10
    ./error.cue:8:18
out.alpha.bravo.charlie: field `delta` not allowed:
    ./error.cue:5:16
    ./error.cue:5:25
    ./error.cue:8:18
    ./error.cue:8:28

Any help in shining light on the problem would be much appreciated! (And my apologies if I am simply missing something obvious...)

[cueckoo]

Original reply by @myitcv in cuelang/cue#481 (comment)

This looks like a bug to me @powerduncan.

Please can you re-raise this as an issue? (apologies, GitHub discussions is still in beta and the "convert discussion to issue" feature has not landed yet).

Thanks

[cueckoo]

Original reply by @powerduncan in cuelang/cue#481 (comment)

Not a problem. It is filed as #483.

[cueckoo]

Original reply by @mpvl in cuelang/cue#481 (comment)

Working on fixing this. I'm rewriting the closedness computation to be significantly simpler. This is a bit involved, though. Apart from bug fixes, semantics shouldn't change.

[cueckoo]

Original reply by @powerduncan in cuelang/cue#481 (comment)

That's great to hear. Thank you! Two questions:

1. To satisfy my own curiosity, would you mind sharing a quick summary of what needs fixing? Even after trying to isolate the problem, I'm still not sure that I understand what is broken (and how).

2. Are there any resources that you might be able to point me to that could help with debugging evaluation problems like this? I didn't find any of the command line flags supported by cue eval to be helpful (they didn't seem to provide any additional information), and I didn't know where to start with the evaluator/interpreter itself. I ended up just removing lines and statements as long as I got the same error message after the removal, but I'm not even really sure that it is exactly the same error. I understand that CUE is still quite young, but if you have any debugging tips you wouldn't mind sharing, I would much appreciate it.

[cueckoo]

Original reply by @mpvl in cuelang/cue#481 (comment)

I have a fix almost ready that will fix this, hopefully by tomorrow.

[cueckoo]

Original reply by @mpvl in cuelang/cue#481 (comment)

See https://cue-review.googlesource.com/c/cue/+/7002. This fixes this issue.