Wrapping negation of unsigned integers is allowed at runtime but not at comptime

[SpexGuy]

Wrapping negation of unsigned integers is occasionally useful, especially in branchless code. It converts 0 to 0, and 1 to 0xFFFF... . This is perfect for construct masks from booleans. Unfortunately, it doesn't work at comptime. The workarounds here are pretty ugly, here's the simplest one I can come up with that doesn't depend on whether the mask type is signed:

    if (@typeInfo(@TypeOf(.{value})).Struct.fields[0].is_comptime) {
        // Since it's comptime, we don't need this to generate nice code.
        return if (value) ~@as(MaskInt, 0) else 0;
    }

    return -%@intCast(MaskInt, @boolToInt(value));

Wrapping negation should be allowed for sized unsigned integers both at runtime and comptime.

[LemonBoy]

The fix for this is literally shorter than the whole ticket, check out ir_eval_negation_scalar.

[RogierBrussee]

It does not work at compile time because a comptime_int has infinite precision, so how could it "wrap", or do modular arithmetic.

Of course if it is explicitly sized it can. But then one should be forced to use -% (or if it is about using bool's as masks,

n*@boolToInt(b)

)

This is just one more example of the confusion that arising from treating integers at the same time as integers, modular integers and bitfields. (see #7512)

(speaking of which, MaskInt seems to be a comptime version of b8, b16,..)

[SpexGuy]

I'm specifically talking about comptime known tyoed integers, not comptime_int. I think unary minus is already a compile error for unsigned values, but -% should be allowed. No need to use multiplication for a mask, negation works fine and is faster. MaskInt here is any integer type which you want to fill with ones or zeroes, so in a sense it does match your bXX type.

[RogierBrussee]

I completely agree that for known sized integers a unary -% makes just as much sense as binary -% including for comptime known ones.

The compiler should be able to translate n*@boolToInt(b) to n&(-%@boolToInt(b)) itself and depending on whether you want to to think of the int as an integer or as a bit vector one or the other makes more or less sense.