cgen: fix infix expr with number overflow (fix #18905)

[yuyi98]

This PR fix infix expr with number overflow (fix #18905).

• Fix infix expr with number overflow.
• Add test.

fn main() {
	a := u8(255)
	b := u8(1)
	c := a + b

	println(c)
	assert c == 0

	println(a + b)
	assert a + b == 0

	println(a + b < a)
	assert a + b < a
}

PS D:\Test\v\tt1> v run .
0
0
true

[spytheman]

@yuyi98 Good work.

The PR is good on its own, but with it, code translated from C to V, will behave slightly and subtly differently than normal pure V code, and the same looking code, compiled with or without -translated can have different results.

If I understand it correctly, with it:

x := u8(5)
a := int(x * 123)
dump(a)
dump(typeof(a).name)

... will behave the same, as int(u8(x*123)), when x is u8, clipping the overflow, i.e. resulting in: [a.v:3] a: 103

Before, it behaved as int(x)*123, i.e. promoting the smaller type to a larger one, and then doing the multiplication, resulting in: [a.v:3] a: 615 .

I am not sure, if it should be merged. I can see it both ways :-| .

@medvednikov please take a look, and decide what is best for V in the long term here.

[spytheman]

Here is the behavior of the same source code from above, without and with -translated:

#0 08:16:17 ᛋ fix_infix_expr_calc_overflow /v/vnew❱./v run a.v 
[a.v:3] a: 103
[a.v:4] typeof(a).name: int
#0 08:20:25 ᛋ fix_infix_expr_calc_overflow /v/vnew❱./v -translated run a.v 
[a.v:3] a: 615
[a.v:4] typeof(a).name: int
#0 08:20:29 ᛋ fix_infix_expr_calc_overflow /v/vnew❱

The difference in the generated C code is:

<       int a = ((int)((u8)(x * 123)));  // with this PR
---
>       int a = ((int)(x * 123)); // old behavior, or with `-translated`

[joe-conigliaro]

we definitely need to fix the behaviour with -translated

[medvednikov]

somehow C autocasts u8+u8 to an int?
I think Go's behavior is more correct and predictable
so I'm in favor of merging this
it can be handled by c2v, so that the -translated hack can be removed