Problems:
- When iterating over an empty string in a list comprehension, the
result is an empty string. This is a bug, it should be an error.
- When iterating over a non-empty string in a list comprehension, the
expected and unexpected types in the error message are swapped.
- Error messages mention "std.flatMap" when object/list comprehensions
would iterate over a value that is neither array nor string.
```
$ jsonnet --version
Jsonnet commandline interpreter (Go implementation) v0.21.0-rc2
$ jsonnet -e '[a for a in ""]'
""
$ jsonnet -e '[a for a in "b"]'
RUNTIME ERROR: Unexpected type array, expected string
<cmdline>:1:1-17
During evaluation
$ jsonnet -e '{[a]: 1 for a in 2}'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-20
<cmdline>:1:1-20
During evaluation
$ jsonnet -e '[a for a in 1]'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-15
During evaluation
```
FWIW, the C++ implementation does not have any of these problems. It
gives:
```
RUNTIME ERROR: In comprehension, can only iterate over array.
```
In the Go implementation comprehensions are desugared to a call to
std.flatMap which does accept a string in the "arr" parameter.
The fix: Desugar comprehensions to a call to a new hidden builtin which
only accepts arrays.
Fixes multiple issues with stack traces leading to missing
stack trace lines. Also, we no longer put builtin context
on the line which *calls* the builtin as if it was a part
of the builtin itself.
Code for stack trace handling was centralized. We no longer
need traceElement argument in ~every function. Now the stack
trace state is kept solely in the interpreter.
Desugar the locals in object comprehensions
"traditionally" instead of handling them manually.
Object comprehensions allow the locals to depend
on the index variable which means that they are separate
for each field. It doesn't make sense to treat them as
a property of the whole object.
Fixes#358.
* 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.
