sortableNodeArray.compare called panic(err) when parseInt64 or ParseFloat
failed, so a scalar tagged !!int or !!float whose value is not a number
crashed yq with a Go stack trace. An explicit tag in the input document is
enough to trigger it, no unusual expression needed.
Log a warning and compare the raw strings instead, matching the timestamp
branch a few lines above in the same function and the plain string fallback
the function already ends with. Values that do parse still compare
numerically.
The == and != operators matched the raw text of two scalars, so the same
integer written in a different base never matched: `0x10 == 16`,
`0o644 == 420` and `1_000 == 1000` were all false.
This contradicted yq's own comparison operators, which parse those
formats and agree the values are equal - for `0o644`, both `> 419` and
`< 421` are true, yet `== 420` was false. It also contradicted the
documented "Match number" behaviour of `==`.
Give ==/!= the same !!int/!!int branch the comparison operators already
have: parse both sides with the existing parseInt64 helper and compare
the resulting int64s. If either side does not fit in an int64, fall back
to the previous raw match rather than raising a new error. String
globbing, floats and null handling are unchanged.
Fixes#1977
dualfroz
upstream