GeezerVison

Shifts of native ints (i64, i32, i16, u32, u16, u8) were compiled to a plain C shift. In C that is undefined behavior when the count is negative or at least the bit width; on x86 the count is effectively masked:

from mypy_extensions import i64, u32

def rshift(x: i64, n: i64) -> i64:
    return x >> n

def lshift(x: u32, n: u32) -> u32:
    return x << n

rshift(-8, 64)  # -8, expected -1
rshift(5, 64)   # 5, expected 0
rshift(8, -1)   # 0, expected ValueError: negative shift count
lshift(1, 32)   # 1, expected 0

With a constant count (e.g. x >> 64 for i64, or x << 40 for i32), the generated C failed to compile ("shift count >= width of type" with -Werror).

Now the plain shift is only used when the count is in range:

• A negative count raises ValueError.
• A count at or above the width gives 0 for left shifts and for right shifts of non-negative or unsigned values, and -1 for a right shift of a negative signed value. This matches int (truncated or wrapped, like other native int shifts).
• Constant counts are resolved at compile time.
• A variable count only adds one unsigned comparison on the fast path, similar to the division-by-zero check for unsigned types.

This also fixes two related codegen issues:

• An integer literal on the left of a shift is now cast to the native int type in C. The type of a C shift is the promoted type of the left operand, so 3 << n with n: i64 was a 32-bit shift.
• Unsigned comparisons of i16 values were missing the uint16_t cast.

Added run tests for all native int types. They cover counts 0, width-1, width, width+1, 64, 100 and negative counts, both constant and variable.