{"entries":[{"lastCommit":{"author":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2026-04-09T15:29:49.000000+01:00"},"committer":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2026-04-09T14:45:40.000000Z"},"hash":"a31acf27c20ec8f1a07668849beb918b63105195","message":"cue/literal: reject leading-zero integers like the parser does\n\nPer the spec, decimal_lit = \"0\" | ( \"1\" … \"9\" ) { [ \"_\" ] decimal_digit },\nso integers with leading zeros like 0000 or 0755 are not valid CUE.\nThe scanner already rejected these, but literal.ParseNum accepted them\nas legacy C/Go-style octal literals, which CUE does not support.\n\nAlso fix the YAML decoder's !!float handler to convert YAML 1.1\nleading-zero octals to the 0o prefix, matching the !!int handler.\nThis nicely resolves a TODO I had spotted myself years ago.\n\nFound via fuzzing.\n\nSigned-off-by: Daniel Martí \nChange-Id: I9cbad6646e494cf56ba692033c7e4cd63119281e\nReviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1235177\nUnity-Result: CUE porcuepine \nReviewed-by: Matthew Sackman \nTryBot-Result: CUEcueckoo \n","tree":"87125960588607f93acc77fd4ac1c0926c610a30"},"mode":"0100644","name":"decode.go","size":29408},{"lastCommit":{"author":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2026-04-09T15:29:49.000000+01:00"},"committer":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2026-04-09T14:45:40.000000Z"},"hash":"a31acf27c20ec8f1a07668849beb918b63105195","message":"cue/literal: reject leading-zero integers like the parser does\n\nPer the spec, decimal_lit = \"0\" | ( \"1\" … \"9\" ) { [ \"_\" ] decimal_digit },\nso integers with leading zeros like 0000 or 0755 are not valid CUE.\nThe scanner already rejected these, but literal.ParseNum accepted them\nas legacy C/Go-style octal literals, which CUE does not support.\n\nAlso fix the YAML decoder's !!float handler to convert YAML 1.1\nleading-zero octals to the 0o prefix, matching the !!int handler.\nThis nicely resolves a TODO I had spotted myself years ago.\n\nFound via fuzzing.\n\nSigned-off-by: Daniel Martí \nChange-Id: I9cbad6646e494cf56ba692033c7e4cd63119281e\nReviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1235177\nUnity-Result: CUE porcuepine \nReviewed-by: Matthew Sackman \nTryBot-Result: CUEcueckoo \n","tree":"87125960588607f93acc77fd4ac1c0926c610a30"},"mode":"0100644","name":"decode_test.go","size":27829},{"lastCommit":{"author":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-04-10T17:14:46.000000+01:00"},"committer":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-04-13T08:34:01.000000Z"},"hash":"069f279aa682f3b0c16f65c930462044d599f4ac","message":"internal: replace ParseAttrBody with ParseAttr\n\nCurrently ParseAttrBody is the only way of creating\nan internal.Attr, but it doesn't populate the Name\nfield because it doesn't have access to it.\n\nIt turns out that everywhere that is currently using ParseAttrBody\ncan also use slightly higher level function that takes\nan ast.Attribute instead. This can usefully populate the\nName and Pos fields from the AST node,\nwhich removes the need for second-guessing of\nthe position logic (as currently done in the cue package).\n\nThere are some places which don't have an ast.Attribute\nalready, but they're only in tests and it's easy to\nconstruct one for the purpose.\n\nWe make ParseAttr return a pointer because it's\nconventional in Go that the constructor for a type\nwith all pointer methods returns a pointer. There's\na small potential performance overhead to this change\nbut this should be negligible compared to what's going\non inside the ParseAttr logic itself.\n\nThe only wrinkle is that most of the places that currently\ncall ParseAttrBody invoke Attribute.Split first to find the\nattribute name. We add an ast.Attribute.Name method\nto make this inspection trivial. This also implies a small\namount of additional runtime overhead, but it should be\nlost in the noise: scanning a few bytes is cheap and\neven cheaper when we've done exactly the same scan\na few instructions previously. I think that the additional\nsimplicity makes this worthwhile.\n\nSigned-off-by: Roger Peppe \nChange-Id: I23eb0e3f997ef520a9a8e3d5abe8b9afde3121dc\nReviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1235347\nTryBot-Result: CUEcueckoo \nUnity-Result: CUE porcuepine \nReviewed-by: Matthew Sackman \n","tree":"5f740c75b45bcf3c7b32100361ca1e52e4a4358c"},"mode":"0100644","name":"encode.go","size":9905},{"lastCommit":{"author":{"email":"19151471+jonas-meyer@users.noreply.github.com","name":"Jonas Meyer-Ohle","when":"2026-02-16T18:35:52.000000Z"},"committer":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2026-02-17T11:30:24.000000Z"},"hash":"b1a58bdd79fdf8176fa163e4601e16ca2af71031","message":"encoding/yaml: add support for YAML tags via `@yaml(,tag)` attribute\n\nThis adds support for encoding YAML tags by specifying them in\n@yaml(tag=\"...\") attributes on CUE fields.\nThe tag value is applied to the encoded YAML node.\n\nThis enables generating YAML files that use custom tags,\nlike those required by authentik blueprints (!KeyOf, !Env, !Find, etc.)\nand other YAML-based tools that rely on tags for special processing.\n\nTags can be applied to scalars, sequences, and mappings.\nThe implementation extracts tags from field attributes in the AST\nand sets them on the corresponding yaml.Node during encoding.\n\nFixes #2316\nCloses #4199 as merged as of commit 1206905c8.\n\nSigned-off-by: Jonas Meyer-Ohle <19151471+jonas-meyer@users.noreply.github.com>\nChange-Id: Ibac6b3c97539a87e215821ffbb71735b4f5330d4\nReviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1231452\nReviewed-by: Daniel Martí \nReviewed-by: Chief Cueckoo \nTryBot-Result: CUEcueckoo \nUnity-Result: CUE porcuepine \n","tree":"00af1662c68254c24665a653a08122223080fe64"},"mode":"0100644","name":"encode_test.go","size":6323},{"lastCommit":{"author":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2024-04-04T14:58:12.000000+09:00"},"committer":{"email":"mvdan@mvdan.cc","name":"Daniel Martí","when":"2024-04-17T11:25:47.000000Z"},"hash":"9fba4fa553dd681a9e766678488f832d2ea32cf1","message":"internal/encoding/yaml: add the new Decoder\n\nThis implementation builds directly on top of gopkg.in/yaml.v3's Decoder\nas opposed to internal/third_party/yaml.Decoder, which forked go-yaml.\n\nThere are a number of differences between the old and new decoders.\nStarting with the disadvantages or minor regressions per decode_test.go:\n\n* yaml.v3's Node only has each node's start position, lacking any end\n or closing token position. As such, empty lists or objects are always\n decoded into a single line even when the YAML was multi-line.\n\n* yaml.v3's Node does not record precise comment positions, so we must\n assume that any HeadComment lines immediately precede the YAML node.\n In some cases this isn't true, and we remove an empty line.\n\n* yaml.v3's errors do not always contain line information, such as\n the \"unknown anchor\" errors already covered in our test suite.\n\nThere are a number of advantages or improvements, though:\n\n* We no longer lose inline or foot/trailing comments in some cases,\n although we continue to lose comments inside empty objects and lists.\n\n* Floating point scalars which are valid CUE integral literals\n are now decoded as `number & N` rather than `float & N`,\n as the latter simply fails, e.g. `float & 123` is an error.\n\n* The test case using simply `v: ! test` works as expected now.\n\nIt should also be noted that an empty YAML input or document decodes\nas a nil ast.Expr in both the old and new decoder, even though the old\ndecoder seemingly intended to decode empty input as a CUE null literal.\nIt returned that null literal alongside an io.EOF error,\nwhich consumers such as internal/encoding and pkg/encoding/yaml ignored\nas they stopped looking at ast.Expr result values at the first error.\n\nAdd a TODO to consider switching the behavior for empty inputs\nto produce a single \"null\" value instead as a separate change.\nAnd for now, continue with the simple design of never returning io.EOF\nalongside any non-nil valid result, to not make changes elsewhere.\n\nThe new decoder is disabled by default and can be enabled via\nCUE_EXPERIMENT=yamlv3decoder - a follow-up CL will enable it by default.\n\nUpdates #3027.\n\nSigned-off-by: Daniel Martí \nChange-Id: I538725c5157924639d7084228d59e3f4e58c6d23\nReviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1191897\nReviewed-by: Roger Peppe \nTryBot-Result: CUEcueckoo \nUnity-Result: CUE porcuepine \n","tree":"a368c17dd3c360a1abffc977dcaab1a6bccbc257"},"mode":"0040000","name":"testdata","size":0},{"lastCommit":{"author":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-02-27T16:48:47.000000Z"},"committer":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-03-02T10:22:32.000000Z"},"hash":"14b457843a37ca5fe73602879eccaedbe21dbec7","message":"internal/core/adt: preparatory work for user-defined functions\n\nWhen introducing user-callable functions, we want to make\na break with the past and not support some of the modes that\nthe current builtin function calls support (like, for example,\nwe want a clear distinction between functions and validators).\n\nIn order to do that, the plan is to introduce a new `adt.Func` type\nto implement the new semantics rather than complicate the\nalready complex `adt.Builtin` logic. That means that we want the\n`CallExpr` logic to be independent of the `Builtin` logic, but they\nare both somewhat intertwined currently.\n\nFactor out `Builtin.rawCall` from `CallExpr.evaluate` in order to\nseparate the two some more, and also rename `CallContext` to\n`BuiltinCallContext` make it clear that the type is about Builtin\ncalls - we will use a different API for `adt.Func`.\n\nThis should have no semantic effect at all.\n\nSigned-off-by: Roger Peppe \nChange-Id: I2d33b14a8cf5c431dd70cc7a9e14930ba43d807f\nReviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1232332\nUnity-Result: CUE porcuepine \nTryBot-Result: CUEcueckoo \nReviewed-by: Daniel Martí \n","tree":"c66e39aa7adef6367335cbfe093b86679361eccc"},"mode":"0100644","name":"validate.go","size":2896}],"lastCommit":{"author":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-04-10T17:14:46.000000+01:00"},"committer":{"email":"rogpeppe@gmail.com","name":"Roger Peppe","when":"2026-04-13T08:34:01.000000Z"},"hash":"069f279aa682f3b0c16f65c930462044d599f4ac","message":"internal: replace ParseAttrBody with ParseAttr\n\nCurrently ParseAttrBody is the only way of creating\nan internal.Attr, but it doesn't populate the Name\nfield because it doesn't have access to it.\n\nIt turns out that everywhere that is currently using ParseAttrBody\ncan also use slightly higher level function that takes\nan ast.Attribute instead. This can usefully populate the\nName and Pos fields from the AST node,\nwhich removes the need for second-guessing of\nthe position logic (as currently done in the cue package).\n\nThere are some places which don't have an ast.Attribute\nalready, but they're only in tests and it's easy to\nconstruct one for the purpose.\n\nWe make ParseAttr return a pointer because it's\nconventional in Go that the constructor for a type\nwith all pointer methods returns a pointer. There's\na small potential performance overhead to this change\nbut this should be negligible compared to what's going\non inside the ParseAttr logic itself.\n\nThe only wrinkle is that most of the places that currently\ncall ParseAttrBody invoke Attribute.Split first to find the\nattribute name. We add an ast.Attribute.Name method\nto make this inspection trivial. This also implies a small\namount of additional runtime overhead, but it should be\nlost in the noise: scanning a few bytes is cheap and\neven cheaper when we've done exactly the same scan\na few instructions previously. I think that the additional\nsimplicity makes this worthwhile.\n\nSigned-off-by: Roger Peppe \nChange-Id: I23eb0e3f997ef520a9a8e3d5abe8b9afde3121dc\nReviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1235347\nTryBot-Result: CUEcueckoo \nUnity-Result: CUE porcuepine \nReviewed-by: Matthew Sackman \n","tree":"5f740c75b45bcf3c7b32100361ca1e52e4a4358c"}}