Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cue: Value.Kind returns BottomKind for open lists #3481

Closed
rogpeppe opened this issue Oct 7, 2024 · 0 comments
Closed

cue: Value.Kind returns BottomKind for open lists #3481

rogpeppe opened this issue Oct 7, 2024 · 0 comments
Labels

Comments

@rogpeppe
Copy link
Member

rogpeppe commented Oct 7, 2024

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

95fd2e94f633c9c32365a6938aac422d1ab48bff

Does this issue reproduce with the latest stable release?

Yes

What did you do?

exec go mod tidy
exec go run .
stdout 'list'
-- go.mod --
module test

require (
	cuelang.org/go v0.11.0-alpha.3.0.20241007084123-95fd2e94f633
)
-- main.go --
package main

import (
	"fmt"

	"cuelang.org/go/cue/cuecontext"
)

func main() {
	ctx := cuecontext.New()
	v := ctx.CompileString(`[1, 2, ...]`)
	if v.Err() != nil {
		panic(v.Err())
	}
	fmt.Println(v.Kind())
}

What did you expect to see?

Passing test. The open list [1, 2, ...] is just as "concrete" as any open struct.

What did you see instead?

> exec go mod tidy
> exec go run .
[stdout]
_|_
> stdout 'list'
FAIL: /tmp/y.txtar:3: no match for `list` found in stdout
cueckoo pushed a commit that referenced this issue Oct 8, 2024
An upcoming change to the CUE API to make lists consistent with structs
for concreteness exposed a reliance of encoding/openapi on the current
inconsistency. It also showed that despite there being logic in
encoding/openapi for dealing with non-empty lists, that logic isn't
tested anyway.

Add a couple of test cases so that the behavior change in the upcoming
CL will be clear.

Note that the results here are not actually valid in OpenAPI 3.0, which
does not support the form of `items` generated here (see #3480).

For #3481

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ib477e11388715482d48c8101d67a47c8efc69f60
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1202243
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
vanhtuan0409 pushed a commit to anduintransaction/cue that referenced this issue Oct 15, 2024
An upcoming change to the CUE API to make lists consistent with structs
for concreteness exposed a reliance of encoding/openapi on the current
inconsistency. It also showed that despite there being logic in
encoding/openapi for dealing with non-empty lists, that logic isn't
tested anyway.

Add a couple of test cases so that the behavior change in the upcoming
CL will be clear.

Note that the results here are not actually valid in OpenAPI 3.0, which
does not support the form of `items` generated here (see cue-lang#3480).

For cue-lang#3481

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ib477e11388715482d48c8101d67a47c8efc69f60
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1202243
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
vanhtuan0409 pushed a commit to anduintransaction/cue that referenced this issue Oct 15, 2024
An open list can be considered concrete just as an open struct can be
considered concrete. This change means that for a CUE value `[1, 2,
...]`, its `Value.Kind` method returns `ListKind` not `BottomKind`.

This necessitated a small change in the OpenAPI logic which was
considering lists concrete when they were closed and all their members
were concrete and populating the "enum" keyword in that case.

Fixes cue-lang#3481.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8a522e4af65a30419cc8cb14e14e120a7d2dec66
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1202244
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant