builtinManifestJSONEx, builtinManifestYamlDoc and builtinManifestTomlEx
use native Go recursion that bypasses MaxStack. A self-referential
object like {a: $} causes unbounded memory allocation until OOM.
Add i.newCall() at the top of each recursive closure, matching the
pattern used by manifestJSON in interpreter.go.
Build Linux aarch64 wheels by extending the build_wheels job in the
workflow to also run on an `ubuntu-22.04-arm` runner.
In order for this to work, the commit also extends the `install-go.sh`
helper architecture aware.
For GitHub first party actions (actions from the github.com/actions
organisation) we just use a major version tag. For actions from any
other source we pin to an exact commit SHA1 (and put the version in
a comment)
This doesn't make them fully correct, in particular directives sections
(e.g., "%YAML 1.2" directive before a document start marker) are not
handled correctly, but they weren't handled correctly before, either.
It also doesn't recognise or try to do anything about document end
markers (`...`).
This fix does allow scalar documents to be on the same line as the
document start tag which is valid per examples in the YAML spec,
see for example https://yaml.org/spec/1.2.1/#id2760844
(YAML 1.2.1 spec, section 2.3 Scalars)
It also matches the C++ jsonnet output for std.parseYaml("42\n---"),
which is a stream of two documents, a scalar and then an empty document
(where the empty document is interpreted as JSON null)
Bumps the go_modules group with 1 update in the / directory: [golang.org/x/crypto](https://github.com/golang/crypto).
Bumps the go_modules group with 1 update in the /examples/bazel directory: [golang.org/x/crypto](https://github.com/golang/crypto).
Updates `golang.org/x/crypto` from 0.36.0 to 0.45.0
- [Commits](https://github.com/golang/crypto/compare/v0.36.0...v0.45.0)
Updates `golang.org/x/crypto` from 0.36.0 to 0.45.0
- [Commits](https://github.com/golang/crypto/compare/v0.36.0...v0.45.0)
---
updated-dependencies:
- dependency-name: golang.org/x/crypto
dependency-version: 0.45.0
dependency-type: direct:production
dependency-group: go_modules
- dependency-name: golang.org/x/crypto
dependency-version: 0.45.0
dependency-type: indirect
dependency-group: go_modules
...
Signed-off-by: dependabot[bot] <support@github.com>
This brings things more into line with modern conventions for
build target names, and means we have fewer sources of truth for
the minimum Go version that's needed.
All the go-jsonnet golden output overrides should be kept here in
the go-jsonnet repo. The older override mechanism (in which the
cpp-jsonnet repo has golden files for Golang ending in .golang)
will be removed.
For https://github.com/google/go-jsonnet/issues/518 to allow users to
keep current behaviour for --string --multi, which on go-jsonnet emitted
output without adding an extra newline.
--no-trailing-newline works with all modes except --yaml-stream.
To avoid confusion, the CLI explicitly rejects the combination of both
flags used together.
This follows the same pattern as I used for the C++ implementation.
Flattening the object is probably also possible, but I think it would
involve binding references to 'super' iff they are satisfied by fields
in existing ancestors and leaving them unbound if they're unsatisfied
so that they can be late-bound by extending the output object.
That seems at least as complicated as defining a new form of
uncachedObject to represent a key-removal operation.
For https://github.com/google/go-jsonnet/issues/830
See also the corresponding C++ jsonnet commit:
82ebe7de83
There are some cases which are a little strange but lexically valid.
- `1.2.3.4` lexically this tokenises as `1.2` DOT `3.4`, because a dot
in the fractional or exponent part of a number is simply treated the
same as any other possible terminating character (any character that
isn't part of the valid number lexical syntax)
- `1e2.34` lexically is `1e2` DOT `34` (same as the first case)
- `1e2e34` lexically is `1e2` (number) `e34` (identifier)
These behaviours are basically preserved/extrapolated in the case of
digit separators, so for example `1_2.3_4.5_6` is lexically parsed
as `12.34` DOT `56`. And `1e2_3e4` is lexically parsed as
`1e23` (number), `e4` (identifier). These both look very confusing,
but it probably doesn't matter because those token sequences are,
I think, not valid syntactically so they'll just be rejected by
the parser.
Note that in JSON (and jsonnet), leading zeros are not allowed in
numeric literals. This behaviour is explicitly kept with digit
separators, so `0_5` is explicitly rejected. The alternatives are:
- Treat underscore after an initial zero the same as any terminator
character, so `0_5` lexes as tokens `0` followed by identifier `_5`.
- Allow underscore, thereby breaking the no-leading-zeros rule, so
`0_5` tokenises as `05`.
Either option seems confusing, hence it seems better to explicitly
reject an underscore after an initial zero.
