This largely doesn't cause filename ordering changes,
as most non-absolute paths on Unix sort after an absolute path
with a leading slash.

The only changes here are in the jsonschema test suite,
where some filenames are empty and used to sort before absolute paths.
Note that sometimes a single empty filename still sorts
before an absolute path (rendered relative to PWD via ./)
because error positions always keep the main position at the beginning.

This should fix flakey tests on Windows,
as absolute paths on that platform typically begin with a drive letter,
so it's much easier for them to sort after relative paths.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I854a762e9183e5b3f64ceeef8e7d12b06cc42a17
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1230090
Reviewed-by: Paul Jolly <paul@myitcv.io>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

We had a test for `package _`, but no test for a missing package line.

While here, ensure that the same applies to `cue fmt --files`,
and remove all output files, which are unnecessary now that this test
can make use of `--check`.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I42c077e6e32c2896dc18347ff94b459bcb1fc8cc
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1230083
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

This method has been hidden and deprecated since April 2021.
We do not have any uses of it ourselves either,
and it has had a clear replacement since day one.
It is time to let it go.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I4eb0d7fe7357204616748108bb148447d5a88ebf
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1230078
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

We seem to have imported this deprecated API from Go back in 2020,
when that was entirely unnecessary at the time.
We don't have any tests nor documentation for it.

The good news is that we never exported any of the OS types in Go,
nor did we expose a HasPrefix func for CUE importers
like we did with IsAbs and others.

Hence, I assume this is an entirely backwards compatible change.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I2a23d4aa7d88678ae922d579b9f68a21c6d60f72
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1230077
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

I was showing CUE to a new user recently and was trying to explain
that `cue vet` is a nice starting point, especially given how
one can use one-liners against schemas in the central registry.

However, the existing help text is verbose and long,
and it omits to mention commonly used features like --list
or how one can validate against a schema from a registry.

Do that rewrite. Keep it brief but useful; a new user does not need
to carefuly understand all the steps that `cue vet` goes through,
or all the different modes that the tool internally understands.

The text also had a hidden mistake: validating data files does not
require passing CUE files; one can use CUE packages just the same.
This was reinforced by all examples using CUE files for schemas.

End the rewrite with modern and realistic examples covering
the three use cases that we find most useful:

1) Checking that a set of packages contain no fatal errors
2) Validating local data against a local schema.
3) Validating local data against a schema in a package from a registry.

Overall we shave 17 lines off of `cue help vet`,
which just barely makes it fit on my screen without needing to scroll.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I003a20a89253d88d5442068d7b7f2740932e469f
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1230080
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Paul Jolly <paul@myitcv.io>

Given that stringifying a CUE value is a rather common need,
and none of the methods or types in this package help with that.

We also add a similar note to the String method,
as we anticipate that some users will look there first.

While here, stop listing the deprecated types;
that takes up valuable space and mental capacity for the reader,
and the types themselves already have visible deprecation notices.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I97f0f7ed99dbd4eb5ebdf6a76d0c8a2a91129a4d
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1230079
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Paul Jolly <paul@myitcv.io>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

Running cue commands from inside the cue.mod directory is a common
mistake for new users. Previously, commands like "cue export ." would
silently work, but others could easily fail in confusing ways.

Now, attempting to load packages from inside cue.mod produces a clear
error message: "cannot load packages inside the cue.mod directory"

The legacy directories cue.mod/pkg, cue.mod/usr, and cue.mod/gen
continue to work for backwards compatibility, as they are still
supported for placing package dependencies. Given that CUE packages
in those locations was commonplace, don't break direct loading of those
directories unless we really have to.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I9defb828d6a0c0b041b21466efce5af9e21efa6a
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229769
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Test running cue commands inside the cue.mod directory,
as well as interacting with packages and files inside of it.

CUE files "inside a module" should be in a directory tree that contains
a cue.mod directory, but not actually inside the cue.mod directory.
However, it's easy for new users to think otherwise and drop CUE code
inside the cue.mod directory somewhere, leading to confusing results.

This commit does not change any behavior; we simply reflect
the current behavior via a test.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I943f8b29e2bceb7a480b0b2c11d9cb6772bb4ffa
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229768
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The codebase is inconsistent about whether cue.mod must be a directory:

- isModRoot() in cue/load/config.go checks existence only, with a comment
noting "cue.mod used to be a file. We still allow both to match."
- Module loading rejects file-based cue.mod with an error message.
- cmd/cue/cmd/modinit.go checks IsDir() and rejects files.

For submodule detection during directory walks, we should be consistent
with isModRoot() and accept either a file or directory. This handles
the case where someone has a legacy cue.mod file marking a submodule.

Simplify the check to just verify cue.mod exists, without requiring
it to be a directory.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I4d089ac6f439057306c0bf2c2992ce5391a59046
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229772
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The directory walk in listFilesInDir was incorrectly checking for
go.mod files to detect submodules, borrowing from Go's module zip code.
CUE uses cue.mod directories instead.

This bug was masked by a second check in checkFiles that correctly
detects files under cue.mod subdirectories and omits them. That check
remains necessary for direct callers of CheckFiles and Create that
pass file lists not obtained from our directory walk.

The directory walk check is now consistent: it skips cue.mod
subdirectories at walk time, avoiding unnecessary file enumeration.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: If3ae3607b57e3ac5f92c154e5cac5ba7364beebd
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229771
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Add a test case documenting the current behavior where directories
containing go.mod files are skipped during directory walks. This is
incorrect for CUE, which uses cue.mod directories instead of go.mod
files to mark module boundaries.

The test shows the asymmetry: cue.mod submodules have their files
filtered by CheckFiles ("file is in another module"), while go.mod
submodules are skipped at walk time ("directory is in another module").

This was likely a mistake when borrowing some of the logic from Go
when we initially introduced support for modern OCI-based CUE modules.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I8553bb5cdef83c1fddeb26eed7d7ebd90df9a895
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229770
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

Since we already know the label is a *ast.BasicLit, we can inline
the replacement logic directly rather than using astutil.Apply,
which is overkill for this simple case.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I52ec664cc1a4e80d030c5df46c69dadc4b2d422a
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229773
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

Only files in the same module containing the CUE file can be embedded.
Parent directory references are not allowed, which was not clear
from the documentation.

Update the Go package docs and help text, and add a test case.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Icc7c4588804d37135644f50e8c0e5c1f5d2eeac4
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229764
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

git mv/rm/rebase, go doc, and more variants of go test.

While here, reorder the list so that we group by tool.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I97b07527b1e49f29f5d30e4b6201105be091875e
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229763
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

For example, net.ParseCIDR("10.20.30.40/24") returns:

{
prefix_mask: "255.255.255.0"
prefix_len: 24
prefix_addr: "10.20.30.0"
broadcast_addr: "10.20.30.255"
}

The names are chosen to loosely follow the API in Go's net/netip
as well as the basic terminology used on Wikipedia.

We might add more fields to this struct in the future,
as long as it's information that is useful and cheap to compute.

Fixes #4236.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I072c85e62976f7ce1041b00d406938b04638f779
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229761
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

This function checks whether an IP address is contained within a CIDR
network. The IP can be provided as a string or byte list, and the CIDR
must be in standard notation (e.g., "192.168.1.0/24").

The parameter order (ip, cidr) allows using this as a validator:

ip: net.InCIDR("10.0.0.0/8")

The original proposal was to add IPInCIDR, but that reads oddly to me,
and InCIDR with the first parameter being "ip" is already intuitive.
Moreover, later on we also want an API to check if one CIDR overlaps
with another CIDR, and CIDROverlapsCIDR is an even weirder name.
Wanting to call that API OverlapsCIDR, use InCIDR here.

This helps DFS's inventory module, which needed to roll its own version
of this function via lots of builtin calls like strings.Split,
math/bits.Rsh, net.ParseIP, and other logic like string interpolation.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.565Gi ± ∞ ¹ 4.322Gi ± ∞ ¹ -5.33% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 47.29M ± ∞ ¹ 43.96M ± ∞ ¹ -7.04% (p=1.000 n=1)

Fixes #3865.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Iecfe4532d23e9bbaff531eb8ef02a933105da074
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229759
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

When formatting list elements like `...string // comment`, the comma
was placed after the comment instead of before it. The fix collects
trailing comments from the type and defers them until after the comma.

Fixes #4238

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I2b40bab3f5c0c6bed3bd2e010f6a2c2e72c955d8
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229757
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The formatter incorrectly places commas after inline comments in list
elements with ellipsis, e.g. `...string // comment` becomes
`...string // comment,` instead of `...string, // comment`.

For #4238

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I6b1b887195fce3255d88090fc4eb930f446f2f69
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229756
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

When iterating over a struct with an error (e.g., missing required field),
the OpContext would have an error set. The old code used Feature.ToValue
which called ctx.NewString/ctx.NewInt64, and these methods return the
context's error when c.HasErr() is true instead of creating the value.

This caused a spurious cascading error like "key value of dynamic field
must be concrete" even though the key label itself was valid - only the
iterated value had an error.

Fix this by constructing String and Num values directly, bypassing the
error-checking in NewString/NewInt64. The key is always derived from a
valid label, so it should not inherit unrelated errors from the context.

This resolves a todo/p2 in cue/testdata/comprehensions/fields.txtar.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I31c23a193ea67f22ae0c0b5bac14014494f9984a
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229649
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

I keep having to tell Claude to not do these things;
for example, excessive use of "cat <<EOF" or /tmp causes it to ask
for permission to use these new commands and paths,
which interrupts the session for no reason at all.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I4f4daf40786301dc0e0c47cc8930bd85f51e3af7
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229648
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

In JSON, object keys must be quoted. When converting to CUE, where safe,
we convert the string lit to a plain ident. However, because the quote
marks have been lost, it means the literal string has become 2 chars
shorter.

We should add 1 to the starting position of the plain idents.
- This ensures the individual character offsets match up with the
original.
- It also means the start-end range of the ident makes sense.

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I74cb800998953383bd1742a29c21c7555265e9f0
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229647
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

We no longer need to maintain the list of flags manually in help.go,
as https://cuelang.org/cl/1222518 added a generator.

We keep two sections to separate active from completed experiments,
but we completed two experiments without moving them. Do so.

Finally, clarify that we try to keep the fields ordered chronologically.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I6665f8c68d095cd47150ef57b2689bc9909a0698
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229645
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

These are all warnings with suggested fixes to modernize the code.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ie2ab80014d86e6840dd78e2224cd78122eac914f
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229646
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I0eb2892dd108fdffe6e2d339467ef458c546d7a5
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229644
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I77506ea43d3d775a33b44cfaf42f3ff92202e5d7
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229643
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

Quickly searching the spec for the term "hidden" does not take one
to the "exported identifiers" section, which is arguably the most
important aspect of hidden identifiers.

See the confusion in a comment in #2565, for example.

Rephrase the second and third sentences to introduce "hidden",
and also to avoid parentheses, which made the text a bit obtuse.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I50c5d75c679420437b5491f67fe3b19613c4444b
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229636
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Feature.ToValue was called eagerly for every string label before pattern
matching, allocating a *String even though the fast path only needs the
string content. This change retrieves the string directly via
ctx.IndexToString for fast-path cases, only allocating in the slow path.

This also fixes a bug in jsonschema where error patterns were not
handled correctly. The old code checked `!k.IsAnyOf(pattern.Kind())`
before the switch statement, but *Bottom has Kind() == BottomKind (0),
so this check always failed for error patterns, returning false
before the *Bottom case could be reached. The new code handles *Bottom
in the switch before any Kind filtering occurs.

The bug fix cannot be easily separated from the optimization because
both changes affect how pattern matching flows through the code, and
attempts to isolate the fix while keeping the old allocation behavior
were unsuccessful.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.592Gi ± ∞ ¹ 4.565Gi ± ∞ ¹ -0.58% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 47.89M ± ∞ ¹ 47.29M ± ∞ ¹ -1.26% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I2c815823ff2412e32f1fbc967c847bed3101291b
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229642
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The call to updateConjunctInfo(TopKind, id, 0) at the start of
insertValueConjunct was redundant. It created conjunctInfo entries
prematurely with TopKind (all bits set) and no flags, which provides
no useful information for typo checking.

Every code path that needs tracking eventually calls updateConjunctInfo
with actual type information:

- *Vertex with StructMarker: calls updateNodeType(StructKind, ...)
- *Vertex non-data: scheduleVertexConjuncts processes conjuncts individually
- *Vertex with ListMarker: task calls updateListType -> updateNodeType
- *Bottom: error case, no tracking needed
- *Builtin: falls through to updateNodeType or recurses
- All other values: go through updateNodeType(v.Kind(), ...)
- *Top: explicitly calls updateConjunctInfo with cHasTop flag

The early call was either immediately superseded by a more specific call,
or created entries for paths where task scheduling handles tracking later.

Much of this analysis was done by Claude Opus,
to double check that this is correct beyond the lack of test failures.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.593Gi ± ∞ ¹ 4.592Gi ± ∞ ¹ -0.03% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 47.92M ± ∞ ¹ 47.89M ± ∞ ¹ -0.06% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I7b988fc71c3b3db24379123320b6883e39de8223
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229641
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Allocate once rather than twice in the helper.
The use of a one-element array rather than using append
also avoids extra capacity in the slice, which is wasted space.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.613Gi ± ∞ ¹ 4.602Gi ± ∞ ¹ -0.23% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 49.06M ± ∞ ¹ 48.33M ± ∞ ¹ -1.50% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ia1cb03bc80e85603d4525188369dfeedb69f86fb
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229434
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

These functions implement builtins. In the process of converting their
arguments from CUE values to Go values, we already allocate bit.Ints;
hence, it's fine to reuse the first argument to store the result,
because we don't need to keep the first argument around.

If keeping the original value is needed by a caller in the future,
it's always possible to make a copy of it before the call.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.601Gi ± ∞ ¹ 4.593Gi ± ∞ ¹ -0.18% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 48.33M ± ∞ ¹ 47.92M ± ∞ ¹ -0.85% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I6cf680cfae31732985900e25abd05c778ed01f34
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229640
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

These are empty struct types, so there is no need to create
new ones for each value.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.618Gi ± ∞ ¹ 4.613Gi ± ∞ ¹ -0.11% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 49.29M ± ∞ ¹ 49.06M ± ∞ ¹ -0.46% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ifff7bc20d6f73f829eb842f1b2f2891117efb858
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229433
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

These have been unused since my simplification
in https://cuelang.org/cl/1226965.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I1ab396347fa573195302e5ca7ed39e0928cb4ff3
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229432
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

They're also only used for adt.MakeRootConjunct,
which happily uses an empty environment when none is given.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I8cf66bfd91eb445e50851a5fc875499d4db413c4
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229431
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

If we can represent the integer as an int64,
the conversion from math/big.Int to apd.Decimal does not need to go
through an extra apd.BigInt step, which also allocates.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.627Gi ± ∞ ¹ 4.618Gi ± ∞ ¹ -0.20% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 49.61M ± ∞ ¹ 49.29M ± ∞ ¹ -0.64% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I08fcf54ef76ff4d16b531b278cfce79a1ef368ec
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229430
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

Mimicking the change in the last commit in internal/core/convert.

Note that there is one tiny difference in test output here;
given the byte sequence 'a\x80\x95a',
x/text/encoding/unicode inserts two replacement characters for the
two invalid bytes, whereas strings.ToValidUTF8 uses one.
As long as the "rune error" sequence is inserted once, it's fine.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Idc2f78e2f9ca03c0889bda80ce402d1acab9e95a
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229429
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The former is in the standard library since Go 1.13, it's simpler,
and most importantly, it doesn't allocate in the common case
where the input string is already valid UTF-8.

This is not unexpected; x/text/encoding/unicode has way more features,
so it's much harder for it to do nothing in the happy path.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.687Gi ± ∞ ¹ 4.627Gi ± ∞ ¹ -1.28% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 49.86M ± ∞ ¹ 49.61M ± ∞ ¹ -0.50% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I8f08a553a84315f851a6d7dabf4e6c379bdaa50a
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229428
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

Currently `Value.Err` returns a non-nil error for incomplete errors,
even though it might be possible for the value to become complete later.
That isn't great, particularly when we want to unmarshal non-concrete
values into Go structs.

We could potentially change `Value.Err` so that it returns nil in such
cases, but that seems like a potentially dangerous change and might well
break existing clientrs.

Instead we add an `IsIncomplete` function to determine if an error _is_
an incomplete error, and use it inside `Value.Decode` so that we allow
decoding incomplete values when we're decoding into a CUE value.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ia6ddffe226be9f4dd7843915a1cc5f3ed88d33dd
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229425
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

We should be able to decode incomplete values
into Go structs, because those values might yet
become complete.

This shows that it's an error currently. A subsequent
CL will fix that.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I55cd0f92c92d663580bc90e40d54a230c7b73fea
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229424
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

The type embeds adt.CallContext, which has that slice already,
accessible via the Value method.

This helps make CallCtxt a little bit smaller,
reducing the allocated space overhead per func call.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.703Gi ± ∞ ¹ 4.687Gi ± ∞ ¹ -0.34% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 49.86M ± ∞ ¹ 49.86M ± ∞ ¹ +0.00% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ibbce4a10173193979b624b37d3dfab52c6d1c5a0
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229427
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

It is a small struct, weighing as much as seven pointers.
None of the methods need a pointer receiver either,
as they only read from the receiver value.
The extra allocation per func call can really add up
when doing many thousands of calls.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.725Gi ± ∞ ¹ 4.703Gi ± ∞ ¹ -0.48% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 51.05M ± ∞ ¹ 49.86M ± ∞ ¹ -2.34% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I2d7b696ad78be327f2cfa260091cb769969d8169
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229426
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.752Gi ± ∞ ¹ 4.725Gi ± ∞ ¹ -0.57% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 52.86M ± ∞ ¹ 51.05M ± ∞ ¹ -3.43% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ic4d07f104c95651c0dc14db1931f8bff124c6f5b
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229423
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

We can use a method on the already allocated envComprehension,
whose pointer value is embedded into envYield.

As a bonus, the code is a bit shorter now.

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.765Gi ± ∞ ¹ 4.752Gi ± ∞ ¹ -0.26% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 53.42M ± ∞ ¹ 52.86M ± ∞ ¹ -1.05% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ied7155f0a37b03eb65470b11ac02e7e3610760bc
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229422
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

│ old │ new │
│ B/op │ B/op vs base │
VetInventory 4.772Gi ± ∞ ¹ 4.765Gi ± ∞ ¹ -0.15% (p=1.000 n=1)

│ old │ new │
│ allocs/op │ allocs/op vs base │
VetInventory 53.88M ± ∞ ¹ 53.42M ± ∞ ¹ -0.85% (p=1.000 n=1)

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I2221ab290c2209381bda5e6793183f6c861fa5bb
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229421
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>

receiver.cc was removed months ago; remove the comments relating to it.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I1481dfd8fe82cd07bdebe545978536d24629859b
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1228260
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

To ensure forward compatibility, allow a wider range of token prefixes.
This will allow future token types to be accepted without requiring
changes to the CLI.

Fixes #4235

Change-Id: I751f9af29401a4a7cbc4a0448c6de9fc4d2b746f
Signed-off-by: Rustam Abdullaev <rustamabd@gmail.com>
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229558
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

https://cuelang.org/cl/1208008 prevented infinite recursion in calls by
deferring all Evaluator expressions when evaluated in a cyclic context.
However, this was overly broad and caused calls with literal arguments
(like `or(["west", "east"])`) to be incorrectly deferred,
resulting in empty
results.

The fix narrows the deferral to only CallExpr with reference arguments,
which are the only expressions that can cause infinite recursion.
Calls with literal-only arguments are now evaluated immediately,
even when evaluated from within an unrelated cyclic context.

Fixes #4230

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I50fa693af34e4958034f38aa6616177ece3af7c8
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229416
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

Calls with only literal arguments like `or(["west", "east"])` are
incorrectly deferred when evaluated from within a cyclic context,
resulting in empty results.

For #4230

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ie1ab27303629cb08fc0eefbcb42d8e60dacbc876
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229415
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>

This should reduce the total number of allocations for DFS by about 5%,
as this function alone is directly responsible for over 10% of allocs.

The better solution for them would be reducing the amount of times
the function is called - which is in the millions - but reducing the
overhead of yielding in a "for" comprehension is still nice.

We should be able to better investigate the root cause of so much
for comprehension yielding once they can share their code with
us via Unity, which has not happened yet.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I089dff10ba0c48b523f042f7409f42d7503a0067
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1228795
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

If the pos is relative or invalid (NoPos) then we cannot add to its
absolute offset.

At the same time, standardize on testing for Pos.file == nil as the
indicator of whether a Pos has an absolute component or not; introduce a
Pos.HasAbsPos() method, and use it consistently.

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I58aee09d50298efd8d5cbf2eae690b1b4d4ff752
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229419
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

When reporting an error for a single-form postfix alias with a blank
identifier (e.g., `a~_: 1`), the code accessed `a.Label.Name` but
`a.Label` is nil in the single form. Use `a.Field.Name` instead since
that contains the identifier being validated.

Fixes #4232.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I862c6183ba4d6f48cdf8ba64e5f4778b03a18f69
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1229418
Reviewed-by: Matthew Sackman <matthew@cue.works>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

There was duplication in the existing code: import specs would be
processed both during their own evaluation, and when path evaluation led
to an imported package.

This CL avoids that duplication, leading to simplification of path
traversal code (`expandNavigables`), and greater consistency.

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I806f834a51031ddc746d01cb90d726a188bcbc57
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1229417
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

When formatting error messages containing error("\(self)"), the debug
printer could enter infinite recursion. This occurred because formatting
a value that contains an error would trigger error formatting, which
would create a new printer instance that didn't share the cycle detection
state of the original printer, leading to the value being formatted again.

Fix this by extending ReplaceArg to intercept errors.Error types and
wrap them in an errorFormatter that uses errors.StringWithConfig with
our printer. This ensures nested error formatting uses the same printer
and its cycle detection mechanism.

Fixes #4228

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: Ie4bd9b51e75aa565163f84498cb5a6bf383a5d18
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1228812
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>

The LSP evaluator processes import specs super lazily so that linking
the import spec to the remote pkg evaluator is done as late as possible.
Without this, booting an evaluator would also boot every evaluator for
every imported package. And the transitive closure. So everything in the
import graph would get booted, which we don't want.

So the remote pkg evaluator only gets booted when we really pass into
it. E.g.

-- a.cue --
package a
import "b"
x: b.y
-- b.cue --
package b
y: 12

Only when we resolve the `y` of the path `b.y` do we boot pkg `b`.
But this causes a problem because it means that if you use the entire
package (e.g. changing `x: b.y` to just `x: b`) then pkg b never gets
booted and so we would also never record that pkg b is used by pkg a.

This CL fixes this by detecting when a path component resolves to an
ImportSpec and forcing the evaluation at that time. This still should
ensure that we don't fully evaluate import specs too early, but it does
ensure that the "usedBy" of packages is now correct.

The old behaviour was flakey, and for that reason it's not possible to
write a test that shows the bad behaviour. But manually backporting the
new test and running with -count 10 will show Usages being flakey.

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I5d02df1a5ccb17a9fd38deb22d0581c9f581e8c6
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1228808
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

package x
import "y.com/z"
out: fun(z)

If we ask for the usages of either `z` on line 3, or `y.com/z" on line
2, the same thing happens: we look for usages of the import. This does
correctly find the `z` on line 3, but the way it traverses up the
evaluation tree also means it reaches the top-level pkg navigable, which
means it's marked as escaping from the pkg and so other pkgs in the same
module then get searched and evaluated.

This behaviour is correct except for imports. Imports do not get
automatically exported by the current pkg. So we need to detect this
situation and make sure we cannot consider it escaped from the current
pkg.

The old behaviour wouldn't result in the wrong results, it would just do
unnecessary work. The new code is already exercised by the existing
tests (checked with code coverage). Adding a dedicated test to check
that in this scenario we do not regress and perform extra work would be
extremely difficult, as there's no sensible way to observe the amount of
work done.

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I68c84ec3251ca568370a9710fe3722d9ce0f0fa4
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1228807
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

Previously, we were not sorting the results of these functions at all. I
suspect editors might be re-sorting the results, but it's not certain
from the LSP spec, which is generally silent on ordering (with the
notable exception of completions).

However, the general advice seems to be:
1. Results from the same file as the query should come first
2. The the rest, sorted by filename, then offset

Signed-off-by: Matthew Sackman <matthew@cue.works>
Change-Id: I1691e6107a58fdf999c23d3506a434e2fecef36f
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1228805
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>

Build on top of https://cuelang.org/cl/1219278 as follows:

* Use wrapper types rather than functions for each of the three
unmarshaler interfaces we support, meaning we don't need to create
new function closures each time, which is a little more involved.

* Use a type switch on reflect.Value.Interface(),
as suggested by Roger in another review.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I1f3a359d9c230f3c3f448d4828347fd7b66101a3
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1228806
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Matthew Sackman <matthew@cue.works>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

The indirect function returning multiple different types of unmarshalers
added more conditional branches to Decode than ideal. This wraps up the
logic unto an unmarshalFunc interface that indirect() returns instead,
so now Decode only needs to check if it was given custom unmarshalling
logic or not.

This also removes an unnecessary use of reflection to set the value of
*big.Float values, to avoid needing to also pass a reflect.Value into
the new unmarshalFunc implementations. Updating the pointer itself
should be sufficient in all cases, including setting struct fields, and
a test has been added for this case as a precaution.

cue-lang/cue#4008

Signed-off-by: Stefan Nuxoll <stefan@nuxoll.me>
Change-Id: I08780120cbe62b3a211a6ee0d64d1b146e37b875
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1219278
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Marcel van Lohuizen <mpvl@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

Leading and inner newlines in interpolation expressions are allowed,
but a trailing newline causes an error; hence the TODO.

We add tests for trailing commas too, given that a newline
at the end of a CUE expression typically inserts a comma.

For #309.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I036f12e2854cd9348d2c87e7a5f4159c167c068e
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1228253
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Roger Peppe <rogpeppe@gmail.com>

The CLI should be able to write to these without any file overwriting.

Fixes #3624.
Fixes #3631.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I0d26dedd0a36a97a690eb833c02ccec8dd5325b0
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1227978
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Roger Peppe <rogpeppe@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>