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.
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.
* Gracefully handle encountered regular expression when running jsonnetfmt, adding tests.
* Do not validate verbatim strings.
* Also do not validate string blocks.
* Change golden prefix for formatter tests to fmt.golden to be consistant with cpp version.
We used to treat dummy paths like <stdin>, <std>, <extvar> as
real import locations, which causes obvious problem for importers.
After this change we consistently pass "" (an empty string) as location
for non-imported paths.
We exposed new functions to properly handle all paths.
The first function family, EvaluateFile* which allow evaluating
a Jsonnet program at a specified importable path. It should
be used in most cases.
The second function family, EvaluateAnonymousSnippet* allows evaluating
a snippet without an importable path. It should be used for situations
like the code passed as a commandline argument, stdin, etc.
The old function family, EvaluateSnippet* is now deprecated, but
works the same as before, i.e. the passed filenames are treated
as imported paths.
Changes are required to custom importers to make sure they satisfy
the refined contract.
Fixes#329.
* Extract some test utilities to a separate package.
* Rename some test utilities.
* Internally expose DirectChildren.
* Add LocationRange to some non-expr AST parts,
such as local binds, parameters and object fields.
* Add end-of-file-reached testcases.
There is no reason for external users to directly depend
on parser. It had a few random things exported as well,
namely errors and "children" functions (helpers for AST
traversal).
It was easy to extract the errors package, but I needed to leave
children in parser for now. The errors package was also
made internal, but it's a candidate for making it public
again potentially (if someone wants to display error messages
just like us). For now it's probably too incomplete anyway.
This change has a potential of breaking the existing users
since we technically remove public APIs. These were not needed
or even helpful for actually running Jsonnet code, but perhaps
someone used them anyway.
