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.
We're currently working with the length of the string itself, which is
the number of bytes. That's wrong in these functions which operate at
the level of characters. When applied to a string with a multibyte
character they can return the wrong result. For example, evaluating
`std.rstripChars('• foo\n', '\n')` results in `"• f"`.
What we need to do instead is get the number of runes, and remove one
rune at a time.
This commit fixes a regression in std.manifestJsonEx that caused the
standard library function to error when the given value was an array.
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
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.
