profile
viewpoint
Marcel van Lohuizen mpvl Google Zurich, Switzerland

mpvl/errd 153

Package errd simplifies error and defer handling.

mpvl/errc 70

Package errc simplifies error and defer handling.

cuelang/cuelang.org 19

Source for the https://cuelang.org site

mpvl/unique 8

Package unique provides primitives for finding unique elements of types that implement sort.Interface.

cuelang/lang-js 7

CUE bindings for JS

mpvl/2016-talks 1

Slides and Links to slides for 2016 talks

mpvl/google_auth_proxy 1

A reverse proxy that provides authentication using Google OAuth2

issue commentcuelang/cue

"field not allowed" with 0.3.0-alpha3, not in 0.2.2

This actually touches upon an ambiguity in the spec. Namely whether ... should open up a struct only for regular fields or also for definitions.

The spec also now also allows ...T for structs (not yet allowed by the parser). The semantics for this is similar to JSON Schema's additional constraints and has mainly been introduced to allow encoding that behavior of JSON Schema as well as to make this syntactical element consistent between lists and structs.

It is likely that regular fields and definitions within a struct serve different roles. So applying ...T to both seem unintuitive and likely undesirable. If that is the case, having ... apply to both seems inconsistent.

Currently, this point is also moot, as definitions are allowed to be added in closed structs. But see #543. In that case, ... would have significance and I'm inclined to say that the spec should be clarified to have ... not apply to definitions.

shykes

comment created time in 3 days

issue commentcuelang/cue

Proposal: don't allow the introduction of new (non-hidden) definitions in a closed struct

@seh, I grouped the non-proposal part in discussions under "possible future extensions"

mpvl

comment created time in 3 days

issue commentcuelang/cue

Proposal: don't allow the introduction of new (non-hidden) definitions in a closed struct

@seh: yes, good catch.

@seh: the scoped/ qualified definitions (pkg#limit) are not part of the proposal. The actual proposal only involves the disallowing new definitions in closed structs discussed in the "The Proposal" section.

mpvl

comment created time in 3 days

issue commentcuelang/cue

"field not allowed" with 0.3.0-alpha3, not in 0.2.2

Related reading: https://github.com/cuelang/cue/issues/543

shykes

comment created time in 3 days

issue commentcuelang/cue

"field not allowed" with 0.3.0-alpha3, not in 0.2.2

Analysis: this is a side effect of a bug that allows #foo to match a .... This then, somewhat oddly, cascades onwards to disallowing help.

shykes

comment created time in 3 days

issue openedcuelang/cue

Proposal: don't allow the introduction of new (non-hidden) definitions in a closed struct

Background

Currently, for regular fields, an author of a definition can make backwards-compatible modifications without fear of breaking its user, as long as users do not use this definition in an embedding. This is a great property to have for large-scale engineering.

A backwards compatible change in general is when an API is modified to be more less specific, with the exception for definitions that existing fields may not be removed, unless paired with a catch-all [string]: T or .... This is because, by default, a user may not add a field to a closed struct, so removing a field from the API will break a usage of this definition that specifies this field.

Note that a user may still add fields to an existing definitions by embedding it. In this case, changes to original definition may break its usage. There is a clear distinction between using something as an embedding or not, and being able to give guarantees on the basis or whether or not a definition is used as an embedding is a clear rule. Also vet rules could warn about the use of definitions from outside the current module as an embedding.

The Problem

The problem is that this desirable property does not hold for nested definitions. Consider this definition:

#D: {
    a: int
}

A user of this template could write

foo: #D & {
    #bar: int
}

introducing a new definition in the definition #D. This is allowed because the current closedness rules do not apply to definitions.

Suppose the original definition is now changed to

#D: {
    a: int
   #bar: string
}

This now results in a breakage of foo downstream. This may be fine if both #D and foo are maintained by a single owner, but it is problematic if they are maintained by different organizations. The problem is two-fold: on the one hand the user of #D has no guarantee that the maintainer of #D will not break their usage, while the maintainer of #D cannot introduce a definition in #D without knowing it may break a user.

Note that the same problem does not occur for this snippet

import "acme.com/pkg"

foo: pkg.#D & {
    _#bar: int
}

because hidden definitions are not visible across package boundaries (NOTE: not enforced yet).

Proposal

We propose disallowing adding definitions to closed structs. In the example above, this means that

#D: a: int

foo: #D
foo: #bar: int

would be illegal and result in a #bar not allowed error.

The user could still write

#D: a: int

foo: {
    #D
    #bar: int
}

resulting in the same issue. However, this makes the behavior consistent with regular field and results in a single guideline upon which non-breakage guarantees can rely.

Note that users can still also write

#D: {
    a: int
}

foo: #D
foo: _#bar: int

to work around the issue as well.

Other less tangible benefits of this proposal is that conceptually there are less scenarios in how fields behave, as it makes the behavior of definitions more like that of regular fields. This may result in simpler model for the user and results in simpler code.

Impact and transition

This is a breaking change. An automated rewrite is somewhat complex and would likely need to operate on the semantic level. Detecting breakage cases should be fairly straightforward, an automated rewrite will not though. It likely requires user interaction to decide if an offending inclusion of a definition should be rewritten as a an embedding or a hidden definition.

It would be good to first implement the scoping rules of hidden fields before rolling this change out.

Discussion

Note that what is discussed in this section is NOT a proposal, but rather a discussion on how the remaining limitations could be addressed in the future in a backwards compatible way.

The introduction of definitions may be useful in some cases. For instance, an author of a definition may want to base its definition on another definition, but also introduce a definition with some common patterns for its users. For instance

// amce.com/foo
package foo

#A: {
  a: int
  b: 
}
// example.com/pkg
package pkg

import "acme.com/foo"

#E: foo.#A & {
   #limit: <10 // illegal under the new proposal
  a: #limit
  b: #limit
}

Users of #E could write

import "example.com/pkg"

e: pkg.#E & { #limit: <5 }

to collectively tighten the limit of all fields.

To work around the limitations of the new proposal, the author could either use embeddings or a hidden definition. In this case, however, neither are satisfactory. It cannot be hidden, because users of the package are supposed to modify #limit and this it cannot be hidden. Using embedding brings us back to square one, as the author of #A could introduce #limit later on and break #E.

To resolve this issue, we could introduce qualified definitions that live in the namespace of the package in which they are defined. Syntactically, this could look like:

// example.com/pkg
package pkg

import "acme.com/foo"

#E: foo.#A & {
  pkg#limit: <10
  a: pkg#limit
  b: pkg#limit
}

Here pkg#limit is a broadening of the identifier syntax, where a # may be preceded not just by _, but any valid regular CUE identifier. The identifier here either refers to the handle of the current package or an imported package, fully qualifying the namespace of the definition. So in the example, pkg#limit is qualified by the tuple ("acme.com/foo", #limit).

A usage of #E would look like:

import "example.com/pkg"

e: pkg.#E & { pkg#limit: <5 }

This mechanism would allow authors to introduce definitions in a backwards compatible way without worrying about breaking things downstream or being broken by an upstream change.

This mechanism would only apply to definitions and not to regular fields. Regular fields are considered what ends up ultimately in a generated configuration and inherently represent a flat space. Definitions don't have this restriction and can benefit from the scoping results as introduced in this paragraph.

Note the close relation of scoped definitions with hidden definitions: 1) both are allowed to introduce a new definition within a closed struct (must be in the current package in both cases), 2) both have an additional qualifier before the # in a definition name, 3) in both cases the meaning of this qualifier is some fully qualified package path (which may be the current package).

We reiterate, that the discussion of scoped definitions is missing a lot of details and is intended to be a proposal, but serves as an example to allow scoped definitions in a world where closedness rules apply to non-scoped definitions.

created time in 3 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha ff306b79708eee06adaa73e6fb62449278727101

doc/ref/spec.md: fix spec bug and broken link Change-Id: Ibb578957275ea26c73688d00d291c61e391622d7 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7162 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 7 days

push eventcuelang/homebrew-tap

cue-bot

commit sha 08622911955bb5c1fdfb39ab5130faac70e438c0

Brew formula update for cue version v0.3.0-alpha3

view details

push time in 11 days

release cuelang/cue

v0.3.0-alpha3

released time in 11 days

created tagcuelang/cue

tagv0.3.0-alpha3

Validate and define text-based and dynamic configuration

created time in 11 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha e3a03a1126a7a79be5f773a52114e2e824ec772f

internal/core/adt: exclude definitions in data conversion Definitions incorrectly trigger closedness for sub structures. They also don't belong in data. IMPORTANT: this implies that it is no longer possible to refer to definitions from within tool files. As a workaround we will allow it still for single-instance commands. Fixes #525 Change-Id: I481dd16e7cacb1096f68d446ce1c5349b5cd4531 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7143 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>

view details

push time in 11 days

issue closedcuelang/cue

cmd/cue: invalid bytes argument for field "contents": empty disjunction when using yaml.Marshal in tool step

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +b9b2c54 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

I'm working on a repro that doesn't involve the monstrosity that is the import GitHub workflow schema.

https://gist.github.com/myitcv/82feaf8b4837ee1025387b0aa078ad68

What did you expect to see?

test.yml to be written successfully to the current directory.

What did you see instead?

command.gengithub.write.contents: invalid bytes argument for field "contents": empty disjunction:
    ./x_tool.cue:9:2

In alpha1, this issue was hidden by #461 and #476

closed time in 11 days

myitcv

push eventcuelang/cue

Marcel van Lohuizen

commit sha f5fa0099b92875abfddc82e831f6efc34bb7abaa

internal/core/adt: remove all closedness IDs in ToData The current algorithm missed some, causing closedness to be misalligned down the line. Fixes #526 Change-Id: I177a8f65ae5e8322328baf4224b69ce52c6a5d1e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7142 Reviewed-by: Paul Jolly <paul@myitcv.org.uk>

view details

push time in 11 days

issue closedcuelang/cue

cmd/cue: panic whilst trying to run a command step that has an error

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +b9b2c54 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

This is a variant on #525, discovered whilst trying to reduce that issue to a minimal repro.

https://gist.github.com/myitcv/12c7317a3d935979a581ce47a8f2adf7

What did you expect to see?

An error telling me that test does not confirm to the json.#Workflow schema.

What did you see instead?

panic: runtime error: index out of range [3] with length 1 [recovered]
        panic: runtime error: index out of range [3] with length 1

goroutine 1 [running]:
cuelang.org/go/cmd/cue/cmd.recoverError(0xc000711ec8)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:221 +0x95
panic(0xc290a0, 0xc000038440)
        /home/myitcv/gos/src/runtime/panic.go:969 +0x175
cuelang.org/go/internal/core/eval.(*acceptor).node(...)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/closed.go:237
cuelang.org/go/internal/core/eval.(*nodeContext).addValueConjunct(0xc0008a5e40, 0xc0003ef720, 0xd82220, 0xc0003c4d58, 0xc000000003)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:1219 +0x14dd
cuelang.org/go/internal/core/eval.(*nodeContext).addExprConjunct(0xc0008a5e40, 0xc0003ef720, 0xd705a0, 0xc0003c4d58, 0x3)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:925 +0x4aa
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc0001ed980, 0xc0003ccaf0, 0xc00063e1b0, 0x70ec04, 0x0, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:403 +0x1f9
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc0001ed980, 0xc0003ccaf0, 0xc00063e1b0, 0x6d9504, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc0001ed980, 0xc0003ccaf0, 0xc00063e1b0, 0x4)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0008a5ce0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0008a5ce0, 0xc000164001)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0008a5ce0, 0xc000364cd0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc0001ed980, 0xc0003ccaf0, 0xc0001bf440, 0xc000580004, 0x0, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc0001ed980, 0xc0003ccaf0, 0xc0001bf440, 0xc0001af204, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc0001ed980, 0xc0003ccaf0, 0xc0001bf440, 0xc000164a04)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc00035eb00)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc00035eb00, 0xc000164a01)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc00035eb00, 0xc0003f3c00)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc0001ed980, 0xc0003ccaf0, 0xc000164bd0, 0xc000580004, 0x0, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc0001ed980, 0xc0003ccaf0, 0xc000164bd0, 0x6c8404, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc0001ed980, 0xc0003ccaf0, 0xc000164bd0, 0xc000164b04)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc00035e9a0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc00035e9a0, 0xc000164b01)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc00035e9a0, 0xc0003f3b00)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc0001ed980, 0xc0003ccaf0, 0xc000132870, 0xc000020004, 0x0, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc0001ed980, 0xc0003ccaf0, 0xc000132870, 0x4, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc0001ed980, 0xc0003ccaf0, 0xc000132870, 0xc000164b04)
        /home/myitcv/dev/cuelang/cue/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/adt.(*Vertex).Finalize(0xc000132870, 0xc0003ccaf0)
        /home/myitcv/dev/cuelang/cue/internal/core/adt/composite.go:320 +0x51
cuelang.org/go/cue.Merge(0xc0003c4dc0, 0x1, 0x1, 0x1)
        /home/myitcv/dev/cuelang/cue/cue/instance.go:236 +0x14e
cuelang.org/go/cmd/cue/cmd.buildTools(0xc000423e00, 0x11d53f8, 0x0, 0x0, 0xc0003fafd0, 0x0, 0x0, 0x2, 0xc000295c68, 0xb16446)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/common.go:608 +0x50f
cuelang.org/go/cmd/cue/cmd.addSubcommands(0xc000423e00, 0xc000711d88, 0xc0000320a0, 0x2, 0x2, 0xc000000100, 0xc000295cd8, 0x467785)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:333 +0x98
cuelang.org/go/cmd/cue/cmd.New(0xc0000320a0, 0x2, 0x2, 0xc000423e00, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:250 +0x993
cuelang.org/go/cmd/cue/cmd.mainErr(0xd7b1c0, 0xc000036138, 0xc0000320a0, 0x2, 0x2, 0xcbf7c0, 0xc000295f48)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:141 +0x45
cuelang.org/go/cmd/cue/cmd.Main(0xc00007e058)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:127 +0x9c
main.main()
        /home/myitcv/dev/cuelang/cue/cmd/cue/main.go:24 +0x25

closed time in 11 days

myitcv

push eventcuelang/cue

Marcel van Lohuizen

commit sha 1e1fe6ffd1a887750bd4d9d396ee38f2a1aa35cc

internal/core/export: handle scalar values in adt.Vertex Fixes #523 Change-Id: I9662bb76cebb326e012575fbfc8c6ca497d2c278 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7141 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>

view details

push time in 11 days

issue closedcuelang/cue

cue: stack overflow printing a Value

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version 8f079d8fb6bbbcd29bf2b0ea63db0a52bfdfcff5 </pre>

Note this is https://cue.googlesource.com/cue refs/changes/23/7123/1

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

Trying to reduce the problem down, but the general issue arises from using fmt.Printf with a %v verb on a cue.Value that has been unified with a schema.

What did you expect to see?

Success

What did you see instead?

Stack overflow

runtime: goroutine stack exceeds 1000000000-byte limit                                                                                                                                                                       
runtime: sp=0xc020b40390 stack=[0xc020b40000, 0xc040b40000]                                                                                                                                                                  
fatal error: stack overflow                                                                                                                                                                                                  
                                                                                                                                                                                                                             
runtime stack:                                                                                                                                                                                                               
runtime.throw(0xba2d5a, 0xe)                                                                                                                                                                                                 
    /home/myitcv/gos/src/runtime/panic.go:1116 +0x72                                                                                                                                                                         
runtime.newstack()                                                                                                                                                                                                           
    /home/myitcv/gos/src/runtime/stack.go:1060 +0x78d                                                                                                                                                                        
runtime.morestack()                                                                                                                                                                                                          
    /home/myitcv/gos/src/runtime/asm_amd64.s:449 +0x8f                                                                                                                                                                       
                                                                                                                                                                                                                             
goroutine 1 [running]:                                                                                                                                                                                                       
runtime.getitab(0xb11260, 0xb4c400, 0xafc501, 0xb4c400)                                                                                                                                                                      
    /home/myitcv/gos/src/runtime/iface.go:33 +0x385 fp=0xc020b403a0 sp=0xc020b40398 pc=0x40bf25                                                                                                                              
runtime.assertI2I2(0xb11260, 0xc6c320, 0xc0003a9a40, 0xc020b40418, 0x40ce85, 0xafc5c0)                                                                                                                                       
    /home/myitcv/gos/src/runtime/iface.go:472 +0x6a fp=0xc020b403d0 sp=0xc020b403a0 pc=0x40d02a                                                                                                                              
cuelang.org/go/internal/core/adt.MakeConjunct(0xc0003c8af0, 0xc6c320, 0xc0003a9a40, 0x0, 0xc0003a9a40, 0x203001, 0x8, 0x0)                                                                                                   
    /home/myitcv/dev/cuelang/cue/internal/core/adt/composite.go:588 +0x65 fp=0xc020b40428 sp=0xc020b403d0 pc=0x7cea05                                                                                                        
cuelang.org/go/internal/core/adt.MakeRootConjunct(...)                                                                                                                                                                       
    /home/myitcv/dev/cuelang/cue/internal/core/adt/composite.go:579                                                                                                                                                          
cuelang.org/go/internal/core/export.(*conjuncts).addExpr(0xc020b40838, 0xc0003c8af0, 0xc76200, 0xc0003a9a40)                                                                                                                 
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:296 +0xd45 fp=0xc020b405a8 sp=0xc020b40428 pc=0x86ae85                                                                                                         
cuelang.org/go/internal/core/export.(*exporter).mergeValues(0xc00029d020, 0xc000000007, 0xc0113f0a20, 0xc0113e3da0, 0x1, 0x1, 0xc0113ee300, 0x1, 0x1, 0x0, ...)                                                              
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:98 +0x32b fp=0xc020b40990 sp=0xc020b405a8 pc=0x868acb                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).expr(0xc00029d020, 0xc76900, 0xc0113f0a20, 0x0, 0xc0113ee300)                                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:65 +0x1c5 fp=0xc020b40aa0 sp=0xc020b40990 pc=0x868365                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).vertex(0xc00029d020, 0xc0113f0a20, 0x0, 0xc000470150)                                                                                                                        
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:55 +0x8e fp=0xc020b40af0 sp=0xc020b40aa0 pc=0x86eece                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).value(0xc00029d020, 0xc7aae0, 0xc0113f0a20, 0xc0113ee300, 0x1, 0x1, 0x0, 0x0)                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:127 +0xab7 fp=0xc020b40c18 sp=0xc020b40af0 pc=0x86fb97                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).mergeValues(0xc00029d020, 0xc000000007, 0xc0113f0990, 0xc0113e3ce0, 0x1, 0x1, 0xc0113ee2e0, 0x1, 0x1, 0x0, ...)                                                              
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:106 +0x153c fp=0xc020b41000 sp=0xc020b40c18 pc=0x869cdc                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).expr(0xc00029d020, 0xc76900, 0xc0113f0990, 0x0, 0xc0113ee2e0)                                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:65 +0x1c5 fp=0xc020b41110 sp=0xc020b41000 pc=0x868365                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).vertex(0xc00029d020, 0xc0113f0990, 0x0, 0xc000470150)                                                                                                                        
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:55 +0x8e fp=0xc020b41160 sp=0xc020b41110 pc=0x86eece                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).value(0xc00029d020, 0xc7aae0, 0xc0113f0990, 0xc0113ee2e0, 0x1, 0x1, 0x0, 0x0)                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:127 +0xab7 fp=0xc020b41288 sp=0xc020b41160 pc=0x86fb97                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).mergeValues(0xc00029d020, 0xc000000007, 0xc0113f0900, 0xc0113e3c20, 0x1, 0x1, 0xc0113ee2c0, 0x1, 0x1, 0x0, ...)                                                              
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:106 +0x153c fp=0xc020b41670 sp=0xc020b41288 pc=0x869cdc                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).expr(0xc00029d020, 0xc76900, 0xc0113f0900, 0x0, 0xc0113ee2c0)                                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:65 +0x1c5 fp=0xc020b41780 sp=0xc020b41670 pc=0x868365                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).vertex(0xc00029d020, 0xc0113f0900, 0x0, 0xc000470150)                                                                                                                        
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:55 +0x8e fp=0xc020b417d0 sp=0xc020b41780 pc=0x86eece                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).value(0xc00029d020, 0xc7aae0, 0xc0113f0900, 0xc0113ee2c0, 0x1, 0x1, 0x0, 0x0)                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/value.go:127 +0xab7 fp=0xc020b418f8 sp=0xc020b417d0 pc=0x86fb97                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).mergeValues(0xc00029d020, 0xc000000007, 0xc0113f0870, 0xc0113e3b60, 0x1, 0x1, 0xc0113ee2a0, 0x1, 0x1, 0x0, ...)                                                              
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:106 +0x153c fp=0xc020b41ce0 sp=0xc020b418f8 pc=0x869cdc                                                                                                        
cuelang.org/go/internal/core/export.(*exporter).expr(0xc00029d020, 0xc76900, 0xc0113f0870, 0x0, 0xc0113ee2a0)                                                                                                                
    /home/myitcv/dev/cuelang/cue/internal/core/export/expr.go:65 +0x1c5 fp=0xc020b41df0 sp=0xc020b41ce0 pc=0x868365                                                                                                          
cuelang.org/go/internal/core/export.(*exporter).vertex(0xc00029d020, 0xc0113f0870, 0x0, 0xc000470150)
...

closed time in 11 days

myitcv

issue commentcuelang/cue

cmd/cue: panic whilst trying to run a command step that has an error

Reduced to

-- x.cue --
package x

test:      #Workflow
#Workflow: "check_run" | [_, ...]
-- x.txtar --
-- x_tool.cue --
package x

import (
        "tool/file"
        "encoding/yaml"
)

command: gengithub: {
        write: file.Create & {
                filename: "test.yml"
                contents: """
                        # Generated by ci_tool.cue; do not edit

                        \(yaml.Marshal(test))
                        """
        }
}
myitcv

comment created time in 11 days

issue closedcuelang/cue

cmd/cue: panic where command cmd depends on @tag attribute

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +20c637a linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

cue cmd -t greeting=hello prefix

-- cue.mod/module.cue --
module: "mod.com"
-- my_tool.cue --
package tools

import (
	"tool/cli"
)

greeting: string @tag(greeting)

command: prefix: {
	gen: cli.Print & {
		text: greeting
	}
}

What did you expect to see?

Success, with hello printed

What did you see instead?

panic: unreachable [recovered]
        panic: unreachable

goroutine 1 [running]:
cuelang.org/go/cmd/cue/cmd.recoverError(0xc000495ec8)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:221 +0x95
panic(0xb82880, 0xd59510)
        /home/myitcv/gos/src/runtime/panic.go:969 +0x175
cuelang.org/go/internal/core/compile.(*compiler).resolve(0xc00047a3c0, 0xc000357770, 0x10, 0xc508e0)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:396 +0x1225
cuelang.org/go/internal/core/compile.(*compiler).expr(0xc00047a3c0, 0xd82a00, 0xc000357770, 0x38, 0x8)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:719 +0x68a
cuelang.org/go/internal/core/compile.(*compiler).labeledExpr(0xc00047a3c0, 0xc0001993b0, 0xd6a020, 0xc0001993b0, 0xd82a00, 0xc000357770, 0x5, 0x203000)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:708 +0xcf
cuelang.org/go/internal/core/compile.(*compiler).decl(0xc00047a3c0, 0xd81560, 0xc0001993b0, 0xc000165dc0, 0xe0)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:480 +0xf8
cuelang.org/go/internal/core/compile.(*compiler).addDecls(0xc00047a3c0, 0xc000298b10, 0xc0002f6f10, 0x1, 0x1)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:447 +0xda
cuelang.org/go/internal/core/compile.(*compiler).expr(0xc00047a3c0, 0xd82d00, 0xc000357810, 0xd7d500, 0xc00031c700)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:724 +0x16cd
cuelang.org/go/internal/core/compile.(*compiler).expr(0xc00047a3c0, 0xd82820, 0xc000357860, 0x203000, 0xd7f040)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:879 +0xcaa
cuelang.org/go/internal/core/compile.(*compiler).labeledExpr(0xc00047a3c0, 0xc000199340, 0xd6a020, 0xc000199340, 0xd82820, 0xc000357860, 0x40f1d0, 0x203000)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:708 +0xcf
cuelang.org/go/internal/core/compile.(*compiler).decl(0xc00047a3c0, 0xd81560, 0xc000199340, 0xc000494e40, 0x6fa105)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:480 +0xf8
cuelang.org/go/internal/core/compile.(*compiler).addDecls(0xc00047a3c0, 0xc000298ae0, 0xc0002f6f20, 0x1, 0x1)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:447 +0xda
cuelang.org/go/internal/core/compile.(*compiler).expr(0xc00047a3c0, 0xd82d00, 0xc000357950, 0x38, 0x8)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:724 +0x16cd
cuelang.org/go/internal/core/compile.(*compiler).labeledExpr(0xc00047a3c0, 0xc0001992d0, 0xd6a020, 0xc0001992d0, 0xd82d00, 0xc000357950, 0x0, 0x203000)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:708 +0xcf
cuelang.org/go/internal/core/compile.(*compiler).decl(0xc00047a3c0, 0xd81560, 0xc0001992d0, 0xc000198e70, 0x70)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:480 +0xf8
cuelang.org/go/internal/core/compile.(*compiler).addDecls(0xc00047a3c0, 0xc000298ab0, 0xc0002f6f00, 0x1, 0x1)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:447 +0xda
cuelang.org/go/internal/core/compile.(*compiler).expr(0xc00047a3c0, 0xd82d00, 0xc000356b90, 0x40f1d0, 0xc000079370)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:724 +0x16cd
cuelang.org/go/internal/core/compile.(*compiler).labeledExpr(0xc00047a3c0, 0xc000199260, 0xd6a020, 0xc000199260, 0xd82d00, 0xc000356b90, 0x11a0b60, 0x7f76fcb9c108)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:708 +0xcf
cuelang.org/go/internal/core/compile.(*compiler).decl(0xc00047a3c0, 0xd81560, 0xc000199260, 0x0, 0x1)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:480 +0xf8
cuelang.org/go/internal/core/compile.(*compiler).addDecls(0xc00047a3c0, 0xc000298a20, 0xc0001af5c0, 0x4, 0x4)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:447 +0xda
cuelang.org/go/internal/core/compile.(*compiler).compileFiles(0xc00047a3c0, 0xc000206610, 0x1, 0x1, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:243 +0x52b
cuelang.org/go/internal/core/compile.Files(0xc0004957f8, 0xd7d740, 0xc00031c3e0, 0xc000206610, 0x1, 0x1, 0xc000635cb0, 0xc000000000, 0x0)
        /home/myitcv/dev/cuelang/cue/internal/core/compile/compile.go:55 +0xcb
cuelang.org/go/cue.(*Instance).Build(0xc000478800, 0xc00036e000, 0x1)
        /home/myitcv/dev/cuelang/cue/cue/instance.go:256 +0x11b
cuelang.org/go/cmd/cue/cmd.buildTools(0xc000443dc0, 0xc00041efc0, 0x1, 0x1, 0xc000468610, 0x0, 0x2, 0x2, 0xc0002b7c68, 0xb15b06)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/common.go:608 +0x52a
cuelang.org/go/cmd/cue/cmd.addSubcommands(0xc000443dc0, 0xc000495d88, 0xc0000320b0, 0x4, 0x4, 0xc000000100, 0xc0002b7cd8, 0x467785)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:333 +0x98
cuelang.org/go/cmd/cue/cmd.New(0xc0000320b0, 0x4, 0x4, 0xc000443dc0, 0x0, 0x0)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:250 +0x993
cuelang.org/go/cmd/cue/cmd.mainErr(0xd7aec0, 0xc000036138, 0xc0000320b0, 0x4, 0x4, 0xcbf600, 0xc0002b7f48)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:141 +0x45
cuelang.org/go/cmd/cue/cmd.Main(0xc00007c058)
        /home/myitcv/dev/cuelang/cue/cmd/cue/cmd/root.go:127 +0x9c
main.main()
        /home/myitcv/dev/cuelang/cue/cmd/cue/main.go:24 +0x25

closed time in 12 days

myitcv

issue commentcuelang/cue

cmd/cue: panic where command cmd depends on @tag attribute

Fixed with https://cue-review.googlesource.com/c/cue/+/7121.

myitcv

comment created time in 12 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha b9b2c543c986d6b9a6c3756496462a1c20388cf7

internal/core/export: better handling of generated CUE Generated CUE structs can organized somewhat different from the ones computed during evaluation. Most notably, conjuncts can be a Vertex. Handle this. Fixes #499 Change-Id: I752e2d09ab7f49476d331028a75c1a9c8f9d480a Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7123 Reviewed-by: Paul Jolly <paul@myitcv.org.uk> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

push time in 12 days

issue closedcuelang/cue

cue/format: bad output for list of struct values

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version v0.3.0-alpha1.0.20200822112649-c6ade67b538f </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

go run main.go

-- go.mod --
module mod.com

go 1.16

require (
	cuelang.org/go v0.3.0-alpha1.0.20200822112649-c6ade67b538f
	github.com/rogpeppe/go-internal v1.6.1 // indirect
)
-- main.go --
package main

import (
	"fmt"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/format"
	"cuelang.org/go/encoding/gocode/gocodec"
)

type guide struct {
	Terminals []*Terminal
}

type Terminal struct {
	Name        string
	Description string
	Scenarios   map[string]*TerminalScenario
}

type TerminalScenario struct {
	Image string
}

func main() {
	var r cue.Runtime
	enc := gocodec.New(&r, nil)
	g := &guide{
		Terminals: []*Terminal{
			{Name: "Name", Description: "Desc"},
		},
	}
	v, err := enc.Decode(g)
	if err != nil {
		panic(err)
	}
	byts, err := format.Node(v.Syntax())
	if err != nil {
		panic(err)
	}
	fmt.Printf("%s\n", byts)
}

What did you expect to see?

{
        Terminals: [{
                Name:        "Name"
                Description: "Desc"
        }]
}

What did you see instead?

{
        Terminals: {
                []
                0: {
                        Name:        "Name"
                        Description: "Desc"
                }
        }
}

closed time in 12 days

myitcv

push eventcuelang/cue

Marcel van Lohuizen

commit sha bd3dd75cab8dabeaa89ef94f13c1fa9aee34bc1f

cue/load: rewrite pre-resolved files after injection This also moves tag discover to load.Instances to prevent finding tags in imported packages. This "feature" slipped in when moving this functionaltiy to cue/load. Change-Id: Ib04d826d95ffebd152310aaad26d0a896991f076 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7121 Reviewed-by: Paul Jolly <paul@myitcv.org.uk> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

Marcel van Lohuizen

commit sha db18b37e9e4a39f7a28815f3d0007fee6703c4c5

internal/core/adt: prevent nil interface bug for Source Fixes #521 Change-Id: I59c789f72ba9c6597378279f26458d77721a4da1 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7122 Reviewed-by: Paul Jolly <paul@myitcv.org.uk> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

push time in 12 days

issue closedcuelang/cue

cmd/cue: def fails on well-formed CUE

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version v0.3.0-alpha2 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

Ran cue def on the following: https://gist.github.com/myitcv/42c4768f01d1845fe9415166373b15b6

What did you expect to see?

Success (and the regular output of cue def), as I do with v0.2.2

What did you see instead?

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x618985]

goroutine 1 [running]:
cuelang.org/go/cmd/cue/cmd.recoverError(0xc00082fec0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/root.go:221 +0x95
panic(0xbbff80, 0x1190e40)
	/home/myitcv/gos/src/runtime/panic.go:969 +0x175
cuelang.org/go/cue/ast.(*Ident).Pos(0x0, 0xd88980, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cue/ast/ast.go:756 +0x5
cuelang.org/go/internal/core/adt.pos(0xd79980, 0xc0000aed58, 0xc000518bd0, 0x165a4)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/adt/context.go:603 +0x65
cuelang.org/go/internal/core/adt.(*OpContext).NewPosf(0xc000198e00, 0x0, 0x0, 0xc9412a, 0x16, 0xc0007c3aa0, 0x1, 0x1, 0xc0007c3aa0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/adt/errors.go:240 +0xfa
cuelang.org/go/internal/core/adt.(*OpContext).Newf(0xc000198e00, 0xc9412a, 0x16, 0xc0007c3aa0, 0x1, 0x1, 0xc0003ae770)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/adt/errors.go:232 +0x89
cuelang.org/go/internal/core/adt.(*OpContext).NewErrf(...)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/adt/context.go:253
cuelang.org/go/internal/core/eval.(*acceptor).verifyArc(0xc0006a87c0, 0xc000198e00, 0xca0, 0xc0002d1cb0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/closed.go:416 +0x38f
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0002d1cb0, 0xc000580004, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:333 +0x86b
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0002d1cb0, 0xc0006a8904, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0002d1cb0, 0xc000206a04)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0002db600)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0002db600, 0xc0000aeb01)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0002db600, 0xc00029abe0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0003d9dd0, 0xc000580004, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0003d9dd0, 0xc00018dc04, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0003d9dd0, 0xc0003d7304)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0002da160)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0002da160, 0xc000203901)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0002da160, 0xc000736050)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0003d81b0, 0xc000700004, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0003d81b0, 0x6cf504, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0003d81b0, 0xc0003d7504)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0003da000)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0003da000, 0xc0003d7501)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0003da000, 0xc000736900)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0003d8120, 0xc000066804, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0003d8120, 0x6cf504, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0003d8120, 0xc000206e04)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0003cfe40)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0003cfe40, 0xc000206e01)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0003cfe40, 0xc0003b3400)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0000fcc60, 0xc000066804, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0000fcc60, 0x6cf504, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0000fcc60, 0xc0003d7904)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc00015fe40)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc00015fe40, 0xc00015fe01)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc00015fe40, 0xc000733d00)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0003c1440, 0xc000508004, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0003c1440, 0x6cf504, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0003c1440, 0xc0003d6f04)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/eval.(*nodeContext).postDisjunct(0xc0002da9a0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:587 +0x1e9
cuelang.org/go/internal/core/eval.(*nodeContext).updateResult(0xc0002da9a0, 0xc0003d6f01)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:130 +0x32
cuelang.org/go/internal/core/eval.(*nodeContext).tryDisjuncts(0xc0002da9a0, 0xc000733d00)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/disjunct.go:197 +0x16b
cuelang.org/go/internal/core/eval.(*Evaluator).evalVertex(0xc000206f30, 0xc000198e00, 0xc0003c0510, 0xc55f04, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:431 +0x2d1
cuelang.org/go/internal/core/eval.(*Evaluator).UnifyAccept(0xc000206f30, 0xc000198e00, 0xc0003c0510, 0xc0002d7204, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:265 +0x88
cuelang.org/go/internal/core/eval.(*Evaluator).Unify(0xc000206f30, 0xc000198e00, 0xc0003c0510, 0xc000198e04)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/eval/eval.go:239 +0x50
cuelang.org/go/internal/core/adt.(*Vertex).Finalize(0xc0003c0510, 0xc000198e00)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/internal/core/adt/composite.go:320 +0x51
cuelang.org/go/cue.(*Instance).Value(0xc000481a00, 0x6, 0xc000443d80)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cue/instance.go:204 +0x52
cuelang.org/go/cmd/cue/cmd.buildInstances(0xc000443d80, 0xc000437e48, 0x1, 0x1, 0xc0005a0d80, 0xc0005a0d70, 0xc0005a0d60)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/common.go:552 +0x131
cuelang.org/go/cmd/cue/cmd.(*buildPlan).instances(0xc000478000, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/common.go:156 +0x58
cuelang.org/go/cmd/cue/cmd.runDef(0xc000443d80, 0x11e43f8, 0x0, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/def.go:60 +0x129
cuelang.org/go/cmd/cue/cmd.mkRunE.func1(0xc0000d5b80, 0x11e43f8, 0x0, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/root.go:46 +0x6c
github.com/spf13/cobra.(*Command).execute(0xc0000d5b80, 0x11e43f8, 0x0, 0x0, 0xc0000d5b80, 0x11e43f8)
	/home/myitcv/gostuff/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:842 +0x47c
github.com/spf13/cobra.(*Command).ExecuteC(0xc0000d5080, 0x0, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
	/home/myitcv/gostuff/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
cuelang.org/go/cmd/cue/cmd.(*Command).Run(0xc000443d80, 0xd846e0, 0xc000034128, 0x0, 0x0)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/root.go:206 +0x65
cuelang.org/go/cmd/cue/cmd.mainErr(0xd846e0, 0xc000034128, 0xc00000e070, 0x1, 0x1, 0xcc8640, 0xc0002b7f48)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/root.go:145 +0x8a
cuelang.org/go/cmd/cue/cmd.Main(0xc00007e058)
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/cmd/root.go:127 +0x9c
main.main()
	/home/myitcv/gostuff/pkg/mod/cuelang.org/go@v0.3.0-alpha2/cmd/cue/main.go:24 +0x25
exit status 2

closed time in 12 days

myitcv

push eventcuelang/homebrew-tap

cue-bot

commit sha 3e62f8aaed115c17b1940700b84be27316f23457

Brew formula update for cue version v0.3.0-alpha2

view details

push time in 12 days

release cuelang/cue

v0.3.0-alpha2

released time in 12 days

created tagcuelang/cue

tagv0.3.0-alpha2

Validate and define text-based and dynamic configuration

created time in 12 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 20c637a6d25ccd5effc0e557a1b6316d6f175b62

cue/load: relax places where @tag is allowed Currently @tag can already be arbitrarily nested. This now also allows embeddings. It now explicitly disallows fields defined within lists or the scope of an optional field in the help. It also reports an error for invalid tag attributes. These restrictions avoid an injection from being spread to widely by being generated, which may increase the ability to analyze a configuration. But if these restrictions prove to be too cumbersome, they could be removed. Closes #437 Change-Id: I3af3a49adb20e67fcce7c6693d40bfd14aa8eb0b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7082 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 12 days

issue closedcuelang/cue

Tag injection is not working

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version 0.2.1 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

<pre> $ cat test.cue { environment: "prod" | "staging" @tag(env,short=prod|staging) } $ cue eval test.cue -t env=prod </pre>

<!-- If possible, provide a recipe for reproducing the error. -->

What did you expect to see?

<pre> $ cue eval test.cue -t env=prod { environment: "prod" } </pre>

What did you see instead?

<pre> $ cue eval test.cue -t env=prod no tag for "env" $ cue eval -t env=prod test.cue no tag for "env" $ cue eval -t prod test.cue no shorthand for "prod" </pre>

closed time in 12 days

pblkt

push eventcuelang/cue

Ben Ye

commit sha c7c14fdad0cfba8386689cb2468d8ddc21d9cb1b

doc/tutorial/kubernetes: remove a duplicate kind field Signed-off-by: Ben Ye <yb532204897@gmail.com> Closes #485 https://github.com/cuelang/cue/pull/485 GitOrigin-RevId: eddace7360baa193f0d84f46e92f644fad0a35ab Change-Id: I08b9d5d38643f98af06f7c69bf49486eb5d7c112 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7105 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 12 days

PR closed cuelang/cue

doc/tutorial/kubernetes: remove a duplicate kind field cla: yes

Signed-off-by: Ben Ye yb532204897@gmail.com

+0 -1

0 comment

1 changed file

yeya24

pr closed time in 12 days

push eventcuelang/cue

chai2010

commit sha 4f4b7a365c3bb5a0fe77672e1789e8e49c7fbaea

pkg/tool/file/append: create file if none exists. Closes #469 https://github.com/cuelang/cue/pull/469 GitOrigin-RevId: 31a327c32d5b8f2cf5bfc83b55c6b78f27c25dcf Change-Id: If04b565fa97bbb280c4ba515fc042645ade4ca9e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7103 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

chai2010

commit sha d69319c9ffcac6626d7be998c0cc18247419b8b8

all: add missing copyright Closes #470 https://github.com/cuelang/cue/pull/470 GitOrigin-RevId: 8d1f54ab9fcd33dabf03d3ee3c2645798d757b65 Change-Id: I12774efd25d9582b68b3f4e03cba41936c24f280 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7104 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

chai2010

commit sha f25c04d6ad23c7578996a475f6b5dc7daa8996ad

cmd/help: fix example in doc Closes #468 https://github.com/cuelang/cue/pull/468 GitOrigin-RevId: df8fd25f7dc2a3b908b871778d26f3a27936e01a Change-Id: I29bc6f9a8686f3b763825061ab023bfde15705f5 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7102 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 12 days

PR closed cuelang/cue

cmd/help: fix example in doc cla: yes
+3 -3

0 comment

3 changed files

chai2010

pr closed time in 12 days

PR closed cuelang/cue

all: add missing copyright cla: yes
+56 -0

0 comment

4 changed files

chai2010

pr closed time in 12 days

PR closed cuelang/cue

pkg/tool/file/append: create file if none exists. cla: yes
+1 -1

0 comment

1 changed file

chai2010

pr closed time in 12 days

PullRequestReviewEvent

Pull request review commentcuelang/cue

pkg/tool/cli: support ask task

 Print: { 	text: string } -// TODO: // Ask prompts the current console with a message and waits for input. // // Example: //     task: ask: cli.Ask({ //         prompt:   "Are you okay?" //         repsonse: bool //     })-// Ask: {-//  kind: "tool/cli.Ask"+Ask: {+	kind: "tool/cli.Ask" -//  // prompt sends this message to the output.-//  prompt: string+	// prompt sends this message to the output.+	prompt: string -//  // response holds the user's response. If it is a boolean expression it-//  // will interpret the answer using textual yes/ no.-//  response: string | bool-// }+	// response holds the user's response. If it is a boolean expression it+	// will interpret the answer using textual yes/ no.+	response: string | bool

I would probably make this *string | bool.

chai2010

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventcuelang/cue

Marcel van Lohuizen

commit sha 1e8906a3057348ffb7ce1e05ce964db226a64320

cmd/cue/cmd: move injection mechanism to cue/load Less cmd/cue-specific code and prepares for build tag support. Change-Id: Ie9e6397b5c046de601d48cf876dac1ae662bdc69 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7063 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 089f4615fc00a3e46b704eb84d77f354fdf8aa61

cue/load: add support for build tags Fixes #511 Change-Id: I012286cffe357ab7d835ef35e0f5e2ece00b9b89 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7064 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 12 days

issue closedcuelang/cue

cmd/cue: buildconstraint help topic is missing

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +c6ade67 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

cue help buildconstraint

(a la go help buildconstraint that was introduced in Go 1.15)

What did you expect to see?

Information on build constraints.

What did you see instead?

Unknown help topic [`buildconstraint`]

closed time in 12 days

myitcv

push eventcuelang/cue

Marcel van Lohuizen

commit sha 4cce6c4c285f20e13325b0f8acba26de8b222a1a

cue: apply wrapping to all errors in list for valueError and callError. This also improves path and position information. Change-Id: I27edc7fef2e38e4017a9ee62c6f82f967c54d80a Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7085 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 13 days

push eventcuelang/cue

Daniel Martí

commit sha 4c1069232f29f09e708debfc19427ed9bc078bf4

all: fix four previously ignored errors Spotted by staticcheck. Most are pretty simple; error variables we never used, and caused no issues. The openapi change is a bit trickier, since openapi test files include a "$version" top-level field. For now, explicitly ignore that field, just like we do with "-". Change-Id: Ia062bcfad8d25a6f0d8cc114f4d5aee475775727 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6863 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha c264475c38a6c799a3ec9b8bd19f91c6832d2bf2

cue/parser: allow attributes before package and import clauses This is to facilitate "build tags". Change-Id: I8ea85d4f1339a3584e7763d342715b8fad2fe48f Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7062 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>

view details

Daniel Martí

commit sha 1bcb73abb73c9846461d1f1117b22e2a7985da64

update go-internal to pull in fix for Go 1.16 See https://github.com/rogpeppe/go-internal/commit/1115b6af0369aff6bd0766818c61a9a75678c6cc for more details. Before this update, 'go test ./...' would fail to build the test packages using testscript. This does not affect Cue directly just yet, as 1.16 won't be released for another five months, but it does make testing Cue on Go's master version possible again. Change-Id: Ia09a70ebe6631250d6ee2707e91668be979dbeb2 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6981 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha edea6f362d741e2771cac5f4db08148569778cc6

doc/ref/spec.md: fix len count for structs Fixes #344 Change-Id: Iaef0b2e55786fab365f6ef867b877ceeb7663092 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7081 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha faf617cdb66c38996cc1c52623d5b9ec3d5539c5

cmd/cue/cmd: verify issue 236 is fixed Closes #236 Change-Id: Idad78066be5987423cecf6f2319a17e8fda15bbf Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7083 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha c72ce5d98d687160a9439e265fe61f122c6bf7d7

internal/core/eval: fix empty data vertex bug Recognize when an empty Vertex is used as data (e.g. after a Merge) it is not recognized as a struct. Change-Id: I769f123cb0e3403cb520f928b188a78f8a9b28b5 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7084 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

Marcel van Lohuizen

commit sha df01042d6e074b923ef22be92ff270de71cc9589

internal/core/compile: better error message for user-defined errors Fixes #321 Change-Id: I0a04fd56a132a98ae3f143e91c4c185052cee4d7 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7069 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

Marcel van Lohuizen

commit sha d2fdbf0932657dd782bb097ff081e345edfadc96

cue: clean up handling of preamble declarations There is a lot of code that needs to find the cutoff point for preamble vs body in the declarations of an ast.File. This cleans this up. Change-Id: I322542f1d5bade6d67ea70bd1085175e7ff8f7c1 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7086 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

push time in 13 days

issue closedcuelang/cue

cmd/cue: obscure error from disallowed field

commit 52cc7f11efb7567a2e9da3690a61fbaacbcca3bb

The error from running cue vet on the following code is obscure:

X :: [=~ "^x"]: _|_
X :: [_]: _
x: X
x: {
	a: "hello"
	b: 2345
	x: 45
}

The error I get is:

x.x: from source:
    ./m.cue:1:17

closed time in 13 days

rogpeppe

issue closedcuelang/cue

Optional fields in schema not allowed in closed struct while trimming.

Schema:: {
    optional? : string
}
d: Schema 
d: {
    optional: "some"
}

On cue trim fails on this with:

d: field "optional" not allowed in closed struct:
    ./a.cue:7:15

closed time in 13 days

hjain98

issue closedcuelang/cue

spec: len does not count optional fields

The specification says, of the len builtin, that it counts the "number of distinct data fields, including optional".

However it does not actually count optional fields. The following code produces bar: 1, not bar: 2.

foo: {
	a: 1
	b?: 2
}
bar: len(foo)

Counting optional fields would not seem consistent with the statement that "foo?: bar is a shorthand for ["foo"]: bar" because label constraints are not countable in general, so it seems that the spec is probably at fault here.

closed time in 13 days

rogpeppe

push eventcuelang/cue

Marcel van Lohuizen

commit sha bc101b301a6c3fcd2bd998dd8d5e92f570b86fee

cue/load: add tool and test files to BuildFiles if requested This prepares for hoising the injection logic from cmd/cue to this package. This, in turn, also prepares for file-level build tag support. The main change is that for the "special" reorganzation of tool files in `cue/cmd` it now removes the tool files, rather than manually addes them. This is weirder, but coincides with our intention to get rid of this special behavior. Change-Id: I7b61966c709282c7c4b55de303cba8e5a87d2a87 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7061 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 148f67a90e6e8ed3612354b6b59e592d9b0769cd

internal/core: fix incorrect error handling 1: don't double-wrap errors in BinOp. This could happen when a value is passed as a Vertex in API usage. 2: subsumption incorrectly used And op for BinOp. Together these Fixes #461 This also improves reporting of structural errors, although this is not complete and not the goal of this CL. Change-Id: Id021a0eb4fa5628f56167d2fccea7d99dbddf390 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7065 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 80e70b9a590c8c50fc2bd428ed820c21dab52ae6

cue: fix instance error handling Change-Id: I58f26d6526ca2ff972caa3db97072e3dec113332 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7066 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha e71970cdc259603db1221030e4aa5483fdd8b3f1

cmd/cue/cmd: verify issue 322 is fixed Fixes #322 Change-Id: I026d67997e5daec4e833ea75ccf64ec1f965abeb Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7067 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 60c207f64b8064743fa4ff949db86e1014c28177

internal/core/runtime: collect errors for all files in resolve Change-Id: I764461a1f4b86d44c28ef42bdb336ae144cd0b09 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7068 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 13 days

issue closedcuelang/cue

cmd/cue: unused import prevents definition

The following code prints a spurious error because (presumably) the unused import causes the identifiers in x.cue not to be processed.

! exec cue vet
cmp stderr expect-stderr

-- expect-stderr --
imported and not used: "strings":
    ./x.cue:2:8
-- x.cue --
package x
import "strings"

foo: "hello"

-- y.cue --
package x

bar: foo

The error I see is:

imported and not used: "strings":
    ./x.cue:2:8
bar: reference "foo" not found:
    ./y.cue:3:6

Unused imports should be the last thing checked, I think (as in Go).

closed time in 13 days

rogpeppe

issue closedcuelang/cue

cmd/cue: non-concrete string value when tool/file.Create depends on stdout from tool/exec.Run step

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +304b02e linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

exec cue cmd writefile
-- cue.mod/module.cue --
module: "mod.com"
-- hello.txt --
Hello, world!
-- x_tool.cue --
package x

import (
	"strings"
	"tool/exec"
	"tool/file"
)

command: writefile: {
	echo: exec.Run & {
		cmd:    "echo hello.txt"
		stdout: string
	}

	write: file.Create & {
		filename: strings.TrimSpace(echo.stdout)
		contents: "Hello, world!"
	}
}

What did you expect to see?

Succeess.

What did you see instead?

command.writefile: invalid operands _|_(error in call to strings.TrimSpace: non-concrete value string (and 1 more errors)) and "" to '!=' (type _|_ and string)

closed time in 13 days

myitcv

issue commentcuelang/cue

trailing newline not allowed in \() string interpolation

It is a bit different in that argument lists are lists, and this is a single value. I'm inclined to take the Swift approach though. It keeps single-line strings as single-line strings and can be relaxed later if need be.

rogpeppe

comment created time in 14 days

issue commentcuelang/cue

Error with Definition that refers to itself

FTR: Narrowed it down to this:

#Def: {
	match: metrics: string: {}
} | {}

x: #Def
x: match: metrics: "foo": {}

what is happening is that the first disjunct does not match because foo is not allowed down the line. The only viable option is then the empty struct. But for this match is not allowed. So either match or foo is not allowed. Currently, only one of the errors for a conjunction is shown, which in this case was match, resulting in the utterly confusing message.

The solution will be to show all errors for match.

ekarlso

comment created time in 16 days

issue commentcuelang/cue

Error with Definition that refers to itself

The problem is here:

metrics: {string: #PromtailStageMetricsSpec}

(line 74), which should be

metrics: {[string]: #PromtailStageMetricsSpec}

After that fix it works for me.

That is an awfully misleading error message, of course, which will have to be fixed.

ekarlso

comment created time in 16 days

issue commentcuelang/cue

/pkg/crypto/ed25519 `Valid` support

BTW, it is now considerably easier to add builtins.

rudolph9

comment created time in 16 days

issue closedcuelang/cue

eval crashes on cyclic dependencies

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version 0.0.15 darwin/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

<!-- If possible, provide a recipe for reproducing the error. -->

$ cat broken.cue
package broken

Controller ::
	settings: {
		controller: Controller
		endpoint?:  controller.settings.endpoint
	}

$ cue eval 
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0x181c721, 0xe)
	/usr/local/go/src/runtime/panic.go:774 +0x72
runtime.newstack()
	/usr/local/go/src/runtime/stack.go:1046 +0x6e9
runtime.morestack()
	/usr/local/go/src/runtime/asm_amd64.s:449 +0x8f

goroutine 1 [running]:
cuelang.org/go/cue.(*exporter).expr(0xc00025cf40, 0x19384c0, 0xc00025b030, 0x19384c0, 0xc00025b030)
	/Users/mpvl/dev/release/cue/cue/export.go:325 +0x50fa fp=0xc02027e7a0 sp=0xc02027e798 pc=0x136023a
cuelang.org/go/cue.(*exporter).recExpr(0xc00025cf40, 0x1938340, 0xc00026b380, 0x193af80, 0xc00025b030, 0x0, 0x0, 0x0)
	/Users/mpvl/dev/release/cue/cue/export.go:308 +0x2fb fp=0xc02027e7e8 sp=0xc02027e7a0 pc=0x135ad6b
cuelang.org/go/cue.(*exporter).structure(0xc00025cf40, 0xc00025b0a0, 0xc00025b000, 0x19384c0, 0xc00025b0a0)
	/Users/mpvl/dev/release/cue/cue/export.go:800 +0xede fp=0xc02027ea48 sp=0xc02027e7e8 pc=0x1361cae
cuelang.org/go/cue.(*exporter).expr(0xc00025cf40, 0x19384c0, 0xc00025b0a0, 0x0, 0x0)

What did you expect to see?

Validation error caused by cyclic dependency

What did you see instead?

Stack overflow

closed time in 16 days

aluzzardi

issue commentcuelang/cue

Tag injection is not working

It was indeed deliberately somewhat restricted, with the aim to relax things further as needed. The idea was to not burry the tags too much. But as we allow recursive fields anyway, allowing embeddings as well seems more consistent.

The remaining restriction is that it can only be set on non-optional fields. But that may be relaxed too if there is a need for it.

pblkt

comment created time in 16 days

issue closedcuelang/cue

Injection doesn't work with imports

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

commit #1370f0a

Does this issue reproduce with the latest release?

yes

What did you do?

Had a library with some @tag(hi) attribute, then ran cue eval --inject hi=hi.

What did you expect to see?

The value "hi" to be injected.

What did you see instead?

The value "hi" was not injected.

closed time in 16 days

philipdexter

issue closedcuelang/cue

spec: part of struct section renders badly

This doesn't look right to me (specifically the italic "foo" and the part after "shorthand for:):

image

closed time in 16 days

rogpeppe

issue commentcuelang/cue

spec: part of struct section renders badly

looks fixed.

rogpeppe

comment created time in 16 days

issue closedcuelang/cue

cue fmt: misplaced open brace in list iterator

On tip (commit a920a11f10f1c982d1da5ddabf4a973ea41955bd)

The following code:

questions: [
	{
		a:    "b"
	} for q in []
]

formats as:

questions: [
            {
        a: "b"
    } for q in []
]

The opening brace looks like it's in the wrong place.

closed time in 16 days

rogpeppe

issue commentcuelang/cue

cue fmt: misplaced open brace in list iterator

This construct is now removed. The new construct does not seem to suffer from this issue.

rogpeppe

comment created time in 16 days

issue commentcuelang/cue

trailing newline not allowed in \() string interpolation

@rogpeppe, aside from convenience, how would you justify a trailing comma in `"(foo,)"?

Either way, I looked at what Swift does, from where this construct was copied, and they take the following approach: for single-line strings there may be no newline separating \(, expr, and ). For multiline strings there may be a newline on both ends. I like that approach as a compromise.

rogpeppe

comment created time in 16 days

issue commentcuelang/cue

ref/spec: logical operators incorrectly documented

Since we are using && and || a typical C-style syntax for logical operators, it may indeed make sense to adopt C-style semantics.

At least we wouldn't have to change the spec. :)

rogpeppe

comment created time in 16 days

issue commentcuelang/cue

cmd/cue: cue --help doesn't work

@joestringer: I do not have this issue myself. Could you confirm this is still the case with the latest verison.

@rogpeppe: this seems to be fixed. Could you confirm?

rogpeppe

comment created time in 16 days

issue commentcuelang/cue

cmd/cue: unused import prevents definition

Note that foo is actually in file x and actually should be found. If that is the error you saw it is fixed now. I'm not quite sure what you expected to see, but I'll go with that this is fixed.

rogpeppe

comment created time in 16 days

issue commentcuelang/cue

cmd/cue: unused import prevents definition

Not sure I understand this. Would it be okay to see both errors, or is the main problem that the "not used" error is reported in the presence of others?

rogpeppe

comment created time in 16 days

issue closedcuelang/cue

cmd/cue: another unhelpful error message for closed struct

commit 76252f4b7486cf862b0ee4113bbb3c91092d8d11

One for the "I found it hard to pinpoint the error" corpus of error cases:

a: A
a: name: "a"

A :: {
	Dependency
	$type: "atype"
	deps: b: B
}

B ::  {
	Dependency
	$type: "btype"
}

Dependency :: {
	name: string
	deps: [depName=_]: {
		name: depName
	}
	$type: string
	...
}

The error printed by cue vet -c for this is:

A.deps.b: field "$type" not allowed in closed struct:
    ./p.cue:11:2
    ./p.cue:12:9
    ./p.cue:20:9
a.deps.b: field "$type" not allowed in closed struct:
    ./p.cue:11:2
    ./p.cue:12:9
    ./p.cue:20:9

The actual location of the start of the closed struct is at the end of line 17:

	deps: [depName=_]: {

but this location isn't mentioned at all in the error results.

For the record, here's the working version of Dependency:

Dependency :: {
	name: string
	deps: [depName=_]: {
		name: depName
		...
	}
	$type: string
	...
}

closed time in 16 days

rogpeppe

issue commentcuelang/cue

cmd/cue: another unhelpful error message for closed struct

With the new closedness rules, these fields are actually allowed (as Dependency is an embedding) and thus can be extended. Also, error line number reporting has been improved.

Closing this

rogpeppe

comment created time in 16 days

issue closedcuelang/cue

Error with Prometheus based code for k8s

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

https://github.com/ekarlso/cue-prometheus-broken

<pre>

git fetch https://cue.googlesource.com/cue refs/changes/61/6961/2 && git checkout -b change-6961 FETCH_HEAD </pre>

Does this issue reproduce with the latest release?

Yes

What did you do?

https://github.com/ekarlso/cue-prometheus-broken

go get github.com/coreos/prometheus-operator/pkg/apis/monitoring/v1/...@v0.39.0
cue go get github.com/tektoncd/pipeline/pkg/apis/resource/...
cue dump

What did you expect to see?

YAML output that used to work with 0.2.x

What did you see instead?

command.dump: field `match_re` not allowed:
    ./main.cue:16:15
    ./main.cue:147:29

closed time in 16 days

ekarlso

issue commentcuelang/cue

Error with Prometheus based code for k8s

I get different errors. I assume this is fixed with the latest changes in tip.

ekarlso

comment created time in 16 days

issue closedcuelang/cue

Convert booleans in string interpolations

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I often need to convert boolean values to be placed into text files (scripts, configs for programs) ... and cannot resort to a straightforward string interpolation.

String interpolation already converts scalar numeric values to string before inserting them. Boolean values, however, are not converted. This seems a bit uneven, as boolean values have a precise representation in json: true or false and it would make interpolating values much more consistent (and practical)

Having this implemented would make interpolating any scalar value consistent. In the future, more consistence could be gained by actually converting any concrete value to json... (Not part of this request though).

Describe the solution you'd like A clear and concise description of what you want to happen.

<pre> --- in/test.cue --- #mybool: true

a: " (#mybool) interpolation"

--- out/export { "a": "true interpolation" } </pre>

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

The alternative is to use package "strconv.FomratBool", which would produce exactly the same result (no way of adding extra formatting instructions).

But, as hinted above: it begs the question of why numbers are treated as special scalars.

Additional context Add any other context or screenshots about the feature request here.

closed time in 16 days

kumorid

issue commentcuelang/cue

Convert booleans in string interpolations

Fixed by 30ca0629cdcc2668bb2972691609300db2b3a52a. (Wrong issue number in commit message so wasn't closed automatically.)

kumorid

comment created time in 16 days

IssuesEvent

issue commentcuelang/cue

cmd/cue: no error in presence of apparently empty list passed to or builtin

Closed due to typo. Reopening.

myitcv

comment created time in 16 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 62528c3cc4f2bc1cd63b19142e8c00be613ea395

internal/core/eval: rewrite of closedness algorithm Spec did not change, but simplified algorithm. Fixes many bugs. This also adds a new compaction algorithm. This will be enabled in a follow-up CL. Also: - "not allowed" failure is now registered with child. This allows multiple failures to be recorded naturally, and also retains more of the correct structure. But more importantly, it prevents descending into the substructure, preventing spurious errors. - Position information has changed slightly, mostly for the better. This introduces a regression on trim. See tools/trim/trim_test.go Fixes #271 Fixes #320 Fixes #370 Fixes #471 Fixes #476 Fixes #483 Fixes #490 Fixes #491 Fixes #493 Fixes #494 Fixes #496 Fixes #497 Change-Id: Ia90ebbbafd8cfc768188d33f109a2e33a4cee922 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7002 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha e0c19d128af09a27a26836f967b01387c8c7daf8

internal/core/eval: fix issue 507 Select default when a disjunction is used in for loop sources or selection. Also verify defaults are picked according to spec in other places. Fixes #507 Change-Id: I9b29213c412f2e881ac41e9d6fcd2a3ad9334690 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7022 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 8776561af04a314ba569dc3e31a5e9d71b55ce8a

cmd/cue/cmd: verify issue 425 is fixed Fixes #425 Change-Id: Ie50a613a72401a0a7c2aad63ed4fa4c2c1a753ac Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7041 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha a6ce8695a2d28ddfd1588fffa5079fe288d7d716

internal/core: finalize list in slice Fixes #500 Change-Id: Iecd8f46c36c1765b86d1d86a917d0a0889786a09 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7042 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha df9468e76067b0e651051101d7495d702c6fb09e

internal/core/export: verify issue 349 is fixed Export implements topological sort on fields. Fixes #349 Change-Id: I5cae07fa99cca83d839f89a79b20fd1ac1d93303 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7043 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha fbf9de306e0cae6a561229838feadd5a58f94709

internal/core/eval: verify issue 398 is fixed Fixes #398 Change-Id: Id7d8d4590f6bb531cb58ea4a176d33237c123fb2 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7044 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha ddd99d5d9fb6fe505ec9b41cb4d6ad5a40adff52

internal/core/eval: verify issue 293 is fixed Fixes #293 Change-Id: I48168c62acc68ce03877eed756fee70a3777f754 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7045 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 480e1a1abdde0ebc1ae132e1d3357aabb2c89adf

internal/core/eval: verify issue 299 if fixed Fixes #299 Change-Id: I3a45b40b6273294185e8ba99bbfd61dfb9422d65 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7046 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 17 days

issue closedcuelang/cue

UniqueItems constraint not respected

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version (devel) darwin/amd64 </pre> Compiled from HEAD at d05ea952e37160e206b0bfc9ec86b179ecebf09c

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

yes

What did you do?

import "list"
x: list.UniqueItems
x: [string, ...string]
x: ["x","x"]

What did you expect to see?

Error

What did you see instead?

x: ["x","x"]

closed time in 17 days

robsonmeemo

issue closedcuelang/cue

cannot close field in if statement

cue commit bfdc42340876a79da5eb52477cfb04f5e096968c

cue export on the following Cue source works, but it should not.

T :: {
	if true {
		// We'd like to restrict the possible members of x in this case,
		// but this doesn't work.
		x: close({
			f1: int
		})
	}
	x: _
}
z: T & {
	x: {
		f1: 99
		f2: "i want to disallow this"
	}
}

If x is closed without the if statement, I get the expected error.

closed time in 17 days

rogpeppe

issue closedcuelang/cue

Propagating recursive imports

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

$ cue version  
cue version 0.1.1 linux/amd64

<!-- If you built from source, specify what git tag or commit was used. -->

What did you do?

<!-- If possible, provide a recipe for reproducing the error. -->

cue eval ./pkg:foo
-- cue.mod/module.cue --
module: "example.com"
-- pkg/foo.cue --
package foo
import "example.com/pkg:bar"
bar
z: 3
-- pkg/bar.cue --
package bar
import "example.com/pkg:baz"
baz
y: 2
-- pkg/baz.cue --
package baz
x: 1

What did you expect to see?

x: 1
y: 2
z: 3

What did you see instead?

y: 2
z: 3

Thanks to @mpvl for the clean example.

closed time in 17 days

adkabo

issue closedcuelang/cue

Cue reorders fields when the key overlaps with the builtins

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

master @ 904f561e349f96f336b51430f0ccb9817a361b87 (April 16)

Does this issue reproduce with the latest release?

Yes

What did you do?

ex: {
  "aaa": "aaa",
  "list": "list",
  "zzz": "zzz",
  "AAA": "AAA",
  "html": "html",
  "HTML": "html",
  "ZZZ": "ZZZ",
  "Html": "html",
}

cue eval

What did you expect to see?

The original order

What did you see instead?

keys which overlap with builtins are sorted at the front of the struct. This happens for both definitions and values.

ex: {
    html: "html"
    list: "list"
    aaa:  "aaa"
    zzz:  "zzz"
    AAA:  "AAA"
    HTML: "html"
    ZZZ:  "ZZZ"
    Html: "html"
}

closed time in 17 days

verdverm

issue closedcuelang/cue

pkg/strings: regression: strings.Join fails with new evaluator

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +c6ade67 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

exec cue eval
-- x.cue --
package x

import "strings"

x: strings.Join(strings.Split("test", "")[1:], "")

What did you expect to see?

x: "est"

(per v0.2.2)

What did you see instead?

error in call to strings.Join: not properly initialized (state: 0, value: *adt.ListMarker)

closed time in 17 days

myitcv

issue closedcuelang/cue

Validation doesn't seem to work on lists

$ head list.{cue,json}
==> list.cue <==
[]

==> list.json <==
[]

$ cue vet list.{cue,json}
conflicting values {[], } and [] (mismatched types struct and list)

$ cue version
cue version 0.2.0 linux/amd64

Is it possible to validate a list of objects?

closed time in 17 days

n87

issue closedcuelang/cue

New evaluator issue with list comprehension and preferred values

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

<pre> $ cue version cue version 0.3.0-alpha1 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What did you do?

package x
somelist: [...string] | * []
// Works just fine
foo: [
  for e in somelist {
    "hello foo: \(e)"
  }
]
otherlist: ["something"]
// Works fine as well
z: [
  for e in otherlist {
    "hello z: \(e)"
  }
]
extlist: [...string] | * ["something"]
// Hard to groke error message: "invalid operand extlist (found list, want list or struct):"
bar: [
  for e in extlist {
    "hello bar: \(e)"
  }
]

What did you expect to see?

Works.

What did you see instead?

Third example (bar) doesn't work with confusing error message: "invalid operand extlist (found list, want list or struct):"

(from https://cuelang.slack.com/archives/CLT4FD7KP/p1599152337016600 )

cc @myitcv

This appears to be a regression.

closed time in 17 days

dubo-dubon-duponey

issue closedcuelang/cue

Yet another improper handling of unification?

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version built from source. Commit: c6ade67b538f585a309c52d271b17119cf18f98b </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

yes

What did you do?

<pre> --- in/test.cue #A : _

#N: #A & { f: j: { n: "hi" } }

l: #N </pre>

<!-- If possible, provide a recipe for reproducing the error. -->

What did you expect to see?

<pre> #A: _ #N: { f: { j: { n: "hi" } } } l: { f: { j: { n: "hi" } } } </pre>

What did you see instead?

<pre> l.f: field j not allowed: test.cue:4:3 test.cue:4:6 l.f.j: field n not allowed: test.cue:4:6 test.cue:4:9 </pre>

NOTE: if instead of #A: _ we use #A: {...} we only get the second error:

<pre> l.f.j: field n not allowed: test.cue:4:6 test.cue:4:9 </pre>

closed time in 17 days

kumorid

issue closedcuelang/cue

Improper behavior wrt non-regular fields (e.g., hidden/definitions)

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version built from source. Commit: c6ade67b538f585a309c52d271b17119cf18f98b </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

yes

What did you do?

I am reformulating my configuration. Doing so I ran into a problem, apparently having to do with improper handling of hidden fields in version 0.3.0-alpha1. With 0.2.2 I do not run into this problem.

I show here a very simplified version of the problem.

<pre> --- in/test.cue #A : _

#N: #A & { _E: { name: "hello" } }

l: #N </pre>

Then run

<pre> $ cue eval -a test.cue </pre>

<!-- If possible, provide a recipe for reproducing the error. -->

What did you expect to see?

Probably

<pre> #A: _ #N: { _E: { name: "hello" } } l: { _E: { name: "hello" } } </pre>

What did you see instead?

<pre> l._E: field name not allowed: test.cue:4:3 test.cue:4:7 </pre>

The same behavior is observed if we use #E (a definition) instead of _E a hidden field. The problem apparently disappears if we use E (a regular field)

closed time in 17 days

kumorid

issue closedcuelang/cue

Incorrect disjunction?

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version built from source. Commit: 0b57e437da86cfcc176a1f1577032e41e7d03e99 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

<!-- If possible, provide a recipe for reproducing the error. --> <pre> --- in/test.cue #Artifact: { body: _ other: [string]: int }

#App: #Artifact #Atom: #Artifact

#Both: #App | #Atom

t1: #Both & {body: 3} </pre>

Then run

<pre> $ cue export test.cue </pre>

What did you expect to see?

<pre> { t1: { body: 3 other: {} } } </pre>

What did you see instead?

<pre> t1: field other not allowed: test.cue:1:12 test.cue:9:1 test.cue:11:14 </pre>

Notice that using #Artifact instead of #Both, like in <pre> #Artifact: { body: _ other: [string]: int }

#App: #Artifact #Atom: #Artifact

#Both: #App | #Atom

t1: #Artifact & {body: 3} </pre>

produces the expected result

closed time in 17 days

kumorid

issue closedcuelang/cue

cmd/cue: regression: field X not allowed when definition used as list type

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +4ecec98 linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

I'm unclear whether this is the same underlying cause as https://github.com/cuelang/cue/issues/471

package x

#Prestep: {
	Args: *null | _
}

#PrestepNewUser: #Prestep & {
	Args: #NewUser
}

#NewUser: {
	Repos: [...#Repo]
}

#Repo: {
	Var:     string
	Pattern: *"*" | string
}

x: [...#Repo]
x: [{
	Var: "REPO1"
}]

y: #Repo & {
	Var: "REPO1"
}

z: #PrestepNewUser & {
	Args: {
		Repos: [ {
			Var: "REPO1"
		}]
	}
}

Run:

cue def

What did you expect to see?

What I see with v0.2.2.:

package x

x: [#Repo & {
        Var: "REPO1"
}]
y: #Repo & {
        Var: "REPO1"
}
#Prestep: {
        Args: *null | _
}
#PrestepNewUser: #Prestep & {
        Args: #NewUser
}
#NewUser: {
        Repos: [...#Repo]
}
#Repo: {
        Var:     string
        Pattern: *"*" | string
}
z: #PrestepNewUser & {
        Args: Repos: [{
                Var: "REPO1"
        }]
}

What did you see instead?

z.Args.Repos.0: field `Pattern` not allowed:
    ./x.cue:12:2
    ./x.cue:15:8
    ./x.cue:31:3
    ./x.cue:31:12

Notice that if z is commented out, what remains work:

package x

#Prestep: {
        Args: *null | _
}
#PrestepNewUser: {
        #Prestep
        Args: #NewUser
}
#NewUser: {
        Repos: [...#Repo]
}
#Repo: {
        Var:     string
        Pattern: *"*" | string
}
x: [...#Repo] & [{
        Var: "REPO1"
}]
y: {
        #Repo
        Var: "REPO1"
}

closed time in 17 days

myitcv

issue closedcuelang/cue

close() is not closing struct (0.3.0-alpha1)

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version devel darwin/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

it works as expected with 0.2.2

What did you do?

<pre> -- test.cue -- A: close({ a: 1 b: 2 })

B: A & { c: 3 } </pre>

Now, run

<pre> cue export test.cue </pre>

<!-- If possible, provide a recipe for reproducing the error. -->

What did you expect to see?

An error such as: <pre> B: field "c" not allowed in closed struct: test.cue:8:5 </pre>

What did you see instead?

A happy output, as if A had not been closed:

<pre> { "A": { "a": 1, "b": 2 }, "B": { "a": 1, "c": 3, "b": 2 } } </pre>

closed time in 17 days

kumorid

issue closedcuelang/cue

"field ... not allowed" error

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

$ cue version
cue version 0.3.0-alpha1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

$ 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

What did you expect to see?

No error...

What did you see instead?

field `charlie` not allowed`

Changes from the example above 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

(Converted from discussion thread at the behest of @myitcv.)

closed time in 17 days

powerduncan

issue closedcuelang/cue

cmd/cue: yaml.Marshal fails on #: "working-directory" in command definition

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +304b02e linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

-- x_tool.cue --
package x

import (
        "tool/cli"
        "encoding/yaml"
)

command: dostuff: {
        write: cli.Print & {
                text: "yaml is " + yaml.Marshal(w)
        }
}

command: dostuffloop: {
        for w in l {
                write: cli.Print & {
                        text: "yaml is " + yaml.Marshal(w)
                }
        }
}
-- y.cue --
package x

#Workflow: {
        #: "working-directory": string
}

l: [w]
w: #Workflow & {
}

Notice how the following succeeds:

$ cue cmd dostuffloop
yaml is {}

But the following fails:

$ cue cmd dostuff
command.dostuff: field `"working-directory"` not allowed

What did you expect to see?

Success in both situations.

What did you see instead?

As above.

closed time in 17 days

myitcv

issue closedcuelang/cue

cmd/cue: regression in definition of unification of disjunction

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +304b02e linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

exec cue def

-- cue.mod/module.cue --
module: "mod.com"
-- x.cue --
package x

#a: (#c | #d) & {
	name: string
}

#a1: #c & {
	name: string
}

#a2: #d & {
	name: string
}

#c: {
	name: string
	age:  int
}

#d: {
	name:    string
	address: string
}

What did you expect to see?

Success with the def of the current package printed.

What did you see instead?

Error:

#a: field `address` not allowed:
    ./x.cue:3:1
    ./x.cue:3:17
    ./x.cue:20:5

This appears to work with v0.2.2:

$ cue version
cue version 0.2.2 linux/amd64
$ cue def
package x

#a: (#c | #d) & {
        name: string
}
#c: {
        name: string
        age:  int
}
#d: {
        name:    string
        address: string
}
#a1: #c & {
        name: string
}
#a2: #d & {
        name: string
}

closed time in 17 days

myitcv

issue closedcuelang/cue

cmd/cue: "field not allowed in closed struct" error does not provide enough info

commit 52cc7f11efb7567a2e9da3690a61fbaacbcca3bb

When debugging CUE programs, it's not uncommon to encounter a field "f" not allowed in closed struct error. The location information provided by the current evaluator does not provide information on the sources of the restriction, but only the places where the field is actually defined, which can make it very hard to find the cause of the issue, particularly in larger packages.

Below is a simple example which fails. The actual error output is:

foo: field "y" not allowed in closed struct:
   ./x.cue:10:5

which points to the field, but not to the definition that's the source of the problem and the place that determines what fields are actually allowed.

I've included some possible extra locations that a better error report might contain.

! exec cue export x.cue
cmp stderr expect-stderr

-- expect-stderr --
foo: field "y" not allowed in closed struct:
    ./m.cue:1:8
    ./m.cue:6:9
    ./m.cue:8:6
    ./m.cue:10:5
-- x.cue --
Foo :: {
	x: string
	More
}

More :: [=~ "^x-"]: _

foo: Foo & {
	x: "hello"
	y: "goodbye"
}

closed time in 17 days

rogpeppe

issue closedcuelang/cue

cannot restrict open struct

This succeeds when it should be an error because [_]: _ & close("a": string) should not allow any fields other than "a".

T :: [_]: _
T :: close({"a": string})
x: T
x: {
	a: "hello"
	b: "foo"
}

closed time in 17 days

rogpeppe

issue commentcuelang/cue

spec: Are hidden fields really hidden?

This is indeed not yet implemented.

kumorid

comment created time in 17 days

issue commentcuelang/cue

import failed: no CUE files in k8s.io/api/core/v1

also, run go get k8s.io/api/core/v1 first.

weberc2-tempus

comment created time in 17 days

issue commentcuelang/cue

import failed: no CUE files in k8s.io/api/core/v1

CUE files without a package clause need to be listed explicitly on the command line. So if you add a package clause at the top of the file you're good.

This should be mentioned in a better error message.

weberc2-tempus

comment created time in 17 days

issue commentcuelang/cue

Incorrect type of the function return values

I cannot reproduce this from tip. You you give it another try?

roman-mazur

comment created time in 17 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha d55e2b5b0a41964a57349c932900e12959b76037

internal/core/eval: allow lists resulting from dependent expressions Fixes #494 Change-Id: I4d9e92193156e39e8677ba091250a73881d141b0 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6962 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

Marcel van Lohuizen

commit sha 3d863fc0ecc3ea5d72ce09260ebfb1554a54eb62

internal/core: move CloseID from Environment to Conjunct Change-Id: If83db9714764e30c764c8947cfb3936beafd8bc5 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7001 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

push time in 18 days

issue closedcuelang/cue

Problem with unification?

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version built from source. Commit: 0b57e437da86cfcc176a1f1577032e41e7d03e99 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

I want to produce a list of objects, where one of the fields carries the index of its object's position in the list.

What follows is a simplified version of the approach, specifically the specification of the a label. This specification appears to reveal a potential problem with unification.

To illustrate what we mean, we accompany the main case (a's specification) with the specifications of other fields. It is specially illustrative the specification of c and of the pair #d d.

<!-- If possible, provide a recipe for reproducing the error. --> --- in/test.cue <pre> _Q : [{pos: 0},{pos: 1}]

a: [rn=string]: _Q[0:len(a[rn])] a: ben: [{}]

b: [rn=string]: _Q[0:1] b: ben: [{}]

c: [rn=string]: [...{l: len(a[rn])}] c: ben: [{}]

#d: [rn=string]: [...{pos:uint}] & _Q[0:len(#d[rn])] #d: ben: [{}]

d: #d </pre>

We then run

<pre> $ cue export test.cue </pre>

What did you expect to see?

<pre> { "a": { "ben": [ { "pos": 0 } ] }, "b": { "ben": [ { "pos": 0 } ] }, "c": { "ben": [ { "l": 1 } ] }, "d": { "ben": [ { "pos": 0 } ] } } </pre>

What did you see instead?

<pre> { "a": { "ben": [ {} ] }, "b": { "ben": [ { "pos": 0 } ] }, "c": { "ben": [ { "l": 1 } ] }, "d": { "ben": [ { "pos": 0 } ] } } </pre>

That is, no unification seems to be happening for a, but no error is issued!

One would think that the recursive reference to a keeps len(a[rn]) from being properly computed, but if this were the case, one should expect some error.

In addition, looking at c it seems that such recursion actually is properly handled to compute len(c[rn])

Finally, the almost exactly equal case of #d/d is properly handled.

So, something seems to be wrong.

closed time in 18 days

kumorid

push eventcuelang/cue

Marcel van Lohuizen

commit sha dd0fa8872279d5601c32d9353fc92423653571c1

doc/ref/spec: consider definitions for closedness Definitions were excempted from closedness checks. With this change, it can be guaranteed that if a template writer does not make an existing field more specific and a user doesn't embed the template, the changes cannot break a user. Consider this template: -- pkg.com/foo/foo.cue -- #Def: {} And its usage: -- bar.cue -- import "pkg.com/foo/foo.cue" def: #Def & { #foo: 2 } The introduction of #foo is currently allowed, as closedness is not checked for definitions. So if the original template is no augmented as such -- pkg.com/foo/foo.cue -- #Def: { #foo: 1 } it breaks the user. This means though, that it breaks the property that if a template writer changes their template, it may conflict with a definition that a user may have added. This already holds for regular fields, but that is to be expected. Users can still add definitions by embedding the struct. But the same warning applies in this case for regular fields and definitions, making it more consistent. Breakage can also occur if a template writer makes a template more specific. Again here also, this also holds for regular fields and this also makes definitions more consistent with regular fields. Change-Id: I1e2aedcf6cc4b17f17f9b4a742ca7aac238ae382 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6721 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 30ca0629cdcc2668bb2972691609300db2b3a52a

internal/core/adt: support interpolation of bytes and bool Also fixes bytes interpolation, which was still WIP. For bool: use JSON representation For bytes: assume bytes are UTF-8 and replace illegal characters according to the recommendations of the Unicode consortium and W3C requirement for character encodings. (So not the Go standard for replacement.) Details clarified in spec. Fixes #475. Change-Id: I94c068f8a73a3948194b179a33e556c37692c05f Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6951 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

Marcel van Lohuizen

commit sha 1c54297d2e01dd200a15fc5f3046eb107da8dcd7

cmd/cue/cmd: fix get go package handling A referenced alias in a different file in the same package for a package that was not used within the file in which the alias was referenced itself, resulted in improper handling. Implementation now uses astutil.Sanitize, which allow for more local import handling, resulting in more robust generation. This also allows eliminating some package tracking and the `usedInFile` field. We could rely more on Sanitize, but that is left up to a next round. Fixes #464 Change-Id: Iaaf98f321a7947a6f24ced85edd5218139cbe785 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6961 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>

view details

push time in 18 days

issue closedcuelang/cue

Cue 0.3 - error with tekton code gen

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

304b02e / 0.3 alpha / trunk + fix for #458

Does this issue reproduce with the latest release?

no

What did you do?

git clone git@github.com:ekarlso/cue-tekton-test.git cd cue-tekton-test bash get-modules.sh cue eval

What did you expect to see?

cue eval results showing the def's etc.

What did you see instead?

    ./cue.mod/gen/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1/pipelinerun_types_go_gen.cue:64:23
#PipelineTaskRunSpec.taskPodTemplate: reference "#Template" not found:
    ./cue.mod/gen/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1/pipelinerun_types_go_gen.cue:226:34
#TaskRunSpec.podTemplate: reference "#Template" not found:
    ./cue.mod/gen/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1/taskrun_types_go_gen.cue:42:23

closed time in 18 days

ekarlso

issue closedcuelang/cue

cmd/cue: no error in presence of apparently empty list passed to or builtin

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://cuelang.slack.com/ -->

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

<pre> $ cue version cue version +304b02e linux/amd64 </pre>

<!-- If you built from source, specify what git tag or commit was used. -->

Does this issue reproduce with the latest release?

Yes

What did you do?

Consider first x.cue:

-- x.cue --
package x

#Guide: {
        Terminals: [string]: #Terminal

        Steps: [string]: #Step
}

#TerminalName: or( [ for k, _ in #Guide.Terminals {k}])

#Step: {
        Terminal: #TerminalName
        Cmd:      string
}

#Terminal: {
        Image: string
}

g: #Guide & {
        Terminals: t1: Image: "golang"

        Steps: ls: #Step & {
                Terminal: "t2"
                Cmd:      "ls"
        }
}

cue eval -c x.cue gives no error, despite the fact that "t2" references a non-existent terminal.

If instead we move the definitions of #Step et al inside #Guide:

-- y.cue --
package x

#Guide: {
        Terminals: [string]: #Terminal

        Steps: [string]: #Step

        #TerminalName: or( [ for k, _ in Terminals {k}])

        #Step: {
                Terminal: #TerminalName
                Cmd:      string
        }

        #Terminal: {
                Image: string
        }
}

g: #Guide & {
        Terminals: t1: Image: "golang"

        Steps: ls: #Guide.#Step & {
                Terminal: "t2"
                Cmd:      "ls"
        }
}

Then cue eval -c y.cue gives:

g.Steps.ls.Terminal: empty disjunction

I suspect the poor error message is to be expected in this release. But at least in this case the error is caught (changing "t2" to "t1" fixes the problem).

Not nesting the definitions (the approach in x.cue) feels "wrong" but I can't articulate why. In any case, it feels like there should be an error of some sort in that case because I assume from the lack of error relating to the fact that "t2" is not in the list ["t1"] then the list must be empty. But this should result in an error because or cannot be passed an empty list AFAIK.

Apologies if the language above is a bit loose, but hopefully I've managed to convey the gist of my understanding/the problem.

closed time in 18 days

myitcv

push eventcuelang/cue

Marcel van Lohuizen

commit sha 043c53412497fa1941f6a7a6fef0a59d7be8e77d

doc/ref/spec: clarification on cycles See https://cue-review.googlesource.com/c/cue/+/6522 for details on the specification and, specifically, the test cases. Change-Id: I8f977c8dc09c1dd931fd4d3f2f66e349cb1278ed Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6741 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Paul Jolly

commit sha 6c27cef9ec2b6d5bb46f0bfd5c09dfba84536942

ci: drop go1.12 add go1.15 Switch to code generation happening against 1.14.9 Update README to reflect new minimum version of Go 1.13 Change-Id: If8d790fe6500a708a2ba7fd8737ffd380048a1be Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7021 Reviewed-by: Paul Jolly <paul@myitcv.org.uk>

view details

push time in 18 days

more