This commit adds a config for yamllint, mass-reformats all of
the existing Yaml testcases to pass linting, and adds a Yaml
linting job to the pull-request Github Actions workflow. A few
careful exceptions and ignores were added to the linter's
config to allow keeping our existing Yaml files with minimal
reformatting.
Signed-off-by: Philip Conrad <philipaconrad@gmail.com>
Fixes#4226.
Also
* adds a YAML test to ensure that this works fine end-to-end.
* ci(pull-request): show input on failure
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
There are four variants to this: with or without 'some', and with
only one or two lhs arguments:
a) x in xs
b) k, v in xs
c) some x in xs
d) some k, v in xs
(a) and (b) are handled in the parser, and end up in the AST as
calls to `internal.member_2` and `internal.member_3`:
a) internal.member_2(x, xs)
b) internal.member_4(k, v, xs)
The backing builtin functions iterate over their last arguments,
trying to find a match. If they do, they will return `true`.
In all other cases -- no match, or a type in the last argument that
can't be iterated over (not an array, object or set), it will
return `false`.
As such, they can be used with `not` without any restrictions.
(c) and (d) are rewritten in the compiler, where x', v', and k' are
fresh local vars:
c) x' = xs[_]
d) v' = xs[k']
Since `in` is a new keyword, it's enabled gradually: for now, a new
mechanism of future keyword imports is added. There are new option
arguments in the parser methods, and there's a hook in the parser
code updating its set of enabled future keywords whenever it
encounters an import statement like
import future.keywords.in # enables only "in"
import future.keywords # enables all future keywords
Functionally, these are identical right now: there is only one
future keyword, "in".
Signed-off-by: Stephan Renatus <stephan.renatus@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>
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>
Philip Conrad