embedding a definition list at the top level seems to disregard closedness rules #3487
Open
Description
$ cue version
cue version v0.11.0-alpha.3.0.20241008133719-86fdd970dd65+dirty
go version devel go1.24-356ba0f065 2024-10-07 20:52:38 +0000
-buildmode exe
-compiler gc
DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,multipathtcp=0,randcrash=0,randseednop=0,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
CGO_ENABLED 1
GOARCH amd64
GOOS linux
GOAMD64 v3
vcs git
vcs.revision 86fdd970dd65df005c76875eb3ec9060a04428b5
vcs.time 2024-10-08T13:37:19Z
vcs.modified true
cue.lang.version v0.11.0
env CUE_EXPERIMENT=evalv3=0
! exec cue export input.cue
env CUE_EXPERIMENT=evalv3=1
! exec cue export input.cue
-- input.cue --
#Schema: {
known: string
}
#Schema
{
known: "foo"
unknown: "bar"
}
I expect the testscript above to succeed - unknown should not be an allowed field given that #Schema is a definition, and so it is a closed struct. However, both the old and new evaluator unexpectedly succeed:
> env CUE_EXPERIMENT=evalv3=0
> ! exec cue export input.cue
[stdout]
{
"known": "foo",
"unknown": "bar"
}
FAIL: test.cue:2: unexpected command success
> env CUE_EXPERIMENT=evalv3=1
> ! exec cue export input.cue
[stdout]
{
"known": "foo",
"unknown": "bar"
}
FAIL: test.cue:5: unexpected command success
This is definitely wrong, particularly since placing the values under a field foo makes it work again:
#Schema: {
known: string
}
foo: #Schema
foo: {
known: "foo"
unknown: "bar"
}
It is worth noting that the original example also unexpectedly succeeds when using a list:
#Schema: {
known: string
}
[...#Schema]
[{
known: "foo"
unknown: "bar"
}]