Change in behavior in 1.15 with `in` and float64

[zachaller]

In argo rollouts we had our tests starting to fail on 1.15 it seems that we needed to be explicit in converting to floats which we did not have to before here are two examples.

1.14.0: https://goplay.tools/snippet/gaA2hxV9auw

        env := map[string]interface{}{
		"res": []float64{10, 11},
	}
	code := "10 in res"

	program, err := expr.Compile(code, expr.Env(env))
	fmt.Println(err)

        //output: true

1.15.0: https://goplay.tools/snippet/rZsOUyfRRop

        env := map[string]interface{}{
		"res": []float64{10, 11},
	}
	code := "10 in res"

	program, err := expr.Compile(code, expr.Env(env))
	fmt.Println(err)

        //output: cannot use int as type float64 in array

Working in 1.15.0 with explicit casting: https://goplay.tools/snippet/XBqyWpRfj6I

        env := map[string]interface{}{
		"res": []float64{10, 11},
	}
	code := "float(10) in res"

	program, err := expr.Compile(code, expr.Env(env))
	fmt.Println(err)

        //output: true

Is this expected behavior?

[antonmedv]

I see. The type checker got more strict, looks like in this case, we can bring back int->float conversion.

[antonmedv]

@zachaller Also what about adding Argo's expressions test corpus to directly to expr?

For example, here are expression tests for CrowdSec:

• https://github.com/antonmedv/expr/blob/master/testdata/crowdsec.json
• https://github.com/antonmedv/expr/blob/master/test/crowdsec/crowdsec.go

This way we can prevent such regressions in the future.

[zachaller]

@zachaller Also what about adding Argo's expressions test corpus to directly to expr?

For example, here are expression tests for CrowdSec:

• https://github.com/antonmedv/expr/blob/master/testdata/crowdsec.json
• https://github.com/antonmedv/expr/blob/master/test/crowdsec/crowdsec.go

This way we can prevent such regressions in the future.

Yea, I will spend some time looking into this and opening a PR!

[antonmedv]

Fixed. Let's add Argo expression corpus for repression testing 😉