Semantic errors in infer_ops.rs

[adsharma]

Description in

8b90aba

[jayvdb]

To clarify, infer_ops output is compared against the Python, however very little of the logic in infer_ops is checked by the runnable/printed code, so the results can be different for each language, and the test rig wont notice. The fix for this issue needs to be expanded logic in infer_ops.py to verify all of the logic within it.

[adsharma]

Rules C uses for integer conversions:

https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules

[adsharma]

This is further complicated by the fact that Rust and C use different rules for integer conversions:

#include <stdio.h>
#include <stdint.h>

int16_t add1(int8_t c1, int8_t c2) {
    return c1 + c2;
}

int main()
{
	int8_t c1 = 127;
	int8_t c2 = 100;

        printf("%d\n", add1(c1, c2));  // 227
}

fn add1(c1: i8, c2: i8) -> i16 {
    return (c1 + c2) as i16;
}

fn main()
{
	let c1: i8 = 127;
	let c2: i8 = 100;

        println!("{}", add1(c1, c2));  // -29
}

[adsharma]

 'cpp' PASSED
 'dart' PASSED
 'go' FAILED
 'julia' FAILED
 'kotlin' FAILED
 'nim' FAILED
 'rust' FAILED

One possibility is to generate code in the other 5 languages to have semantics similar to C. Widen to int, perform the operation and then truncate. But the choice of "int" in the C standard seems arbitrary. We could widen to the next integer type with a greater rank that prevents overflow or underflow.

For this case:

def add3(c1: i32, c2: i32):
    return c1 + c2

int64_t add3(int32_t c1, int32_t c2) {
    return (int64_t) c1 + (int64_t) c2;
}

I was completely unaware of the "integer rank" concept in the C language. Glad that the concept matches what I came up with for py2many (RUST_WIDTH_RANK)