The function `array.reverse` takes an array as an argument, and returns an array with a reversed order of elements.
The function `strings.reverse` takes a string as an argument, and returns a string with a reversed order of unicode code points.
WASM support is included for both built-ins.
Fixes#3736
Signed-off-by: Kristian Svalland <kristian.svalland@gmail.com>
* wasm: count() invalid utf-8 runes, don't abort
Previously, we'd bail out when the string count() is given contained
anything that isn't a valid utf-8 rune. Now, we'll have it count the
invalid chars -- they're replaced by chartorune() in the same manner
as happens when passing casting the string to []rune in golang:
package main
import (
"encoding/base64"
"fmt"
)
func main() {
sample, _ := base64.StdEncoding.DecodeString("2E84ZuPUd7zfvCZSNEchVpDEIj6PL7JfLpIqyxVG16k=")
fmt.Printf("% x\n%x\n%d, %d\n", sample, []rune(string(sample)), len(sample), len([]rune(string(sample))))
}
This yields:
d8 4f 38 66 e3 d4 77 bc df bc 26 52 34 47 21 56 90 c4 22 3e 8f 2f b2 5f 2e 92 2a cb 15 46 d7 a9
[fffd 4f 38 66 fffd fffd 77 fffd 7fc 26 52 34 47 21 56 fffd fffd 22 3e fffd 2f fffd 5f 2e fffd 2a fffd 15 46 5e9]
32, 30
Where fffd is the replacement char whenever something isn't a proper rune.
* topdown/builtins: fix indexof() result when using unicode
Previously, indexof() would count unicode characters as strings, so
indexof("μx", "x")
would return 2 insteads of 1.
Now, we're converting to rune and compare explicitly, returnig the
proper result.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
In topdown, we have two different error modes: strict/non-strict.
In WASM, everything is meant to be non-strict. Thus errors that
only appear in topdown with strict mode are annotated as such,
and checked for an empty result-set in the WASM test runner.
Several WASM builtins that have returned an error where they should
return NULL have been adjusted.
This allows us to fix most of the exceptions brought up in #2954.
Notable pieces:
* wasm sdk: ignore builtin errors
This should be in line with the non-strict builtin error semantics used
in WASM.
Before, when the WASM SDK had called out top a topdown-defined builtin,
and that builtin had returned an error, the WASM caller returned that
error. It's been at odds with how topdown evaluated builtin errors when
run without strict builtin errors.
Now, the errors are properly ignored, except for topdown.Halt. That one
doesn't seem like it's used at the moment, at least from this code base.
* cases: add want_result where non-strict eval yields something
This happens to work for both topdown and wasm:
- in topdown, the test runner checks for expected errors first, and
ignores the wanted result;
- in wasm, we check for a desired result first, checking the error
if no result was defined.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
Since anything can happen, we now list the possibilities (3! = 6),
and check that any of them was the result.
Fixes#2924.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
This is done by working with the runes directly, both when counting length of strings as well as when slicing them to substrings.
Fixes#2799
Signed-off-by: Anders Eknert <anders.eknert@bisnode.com>
Anders Eknert