Can you add a regression test to test/compile_errors.zig?

The CI failure is interesting... #1159 must be causing it but the run for that PR was green.

I think rerunning the build would resolve the issue in Travis.

I know this issue has been closed, but its the closest to this error I'm getting:

test "error: LHS of shift..." {
    var idx: u64 = 0;
    var result: u64 = 0;
    while (idx < 64) : (idx += 1) {
        result |= 1 << idx;
    }
}

... error: LHS of shift must be an integer type, or RHS must be compile-time known
        result |= 1 << idx;
                    ^

Can anyone spot the problem? If I cast the 1 as u64, I get a different error.

test "error: expected type 'u6', found 'u64'" {
    var idx: u64 = 0;
    var result: u64 = 0;
    while (idx < 64) : (idx += 1) {
        result |= u64(1) << idx;
    }
}

... error: expected type 'u6', found 'u64'
        result |= u64(1) << u6(idx);
                              ^

Should I create a new issue for this? Am I missing something? I just want to do a simple shift. I take it the compiler is checking to make sure I can't overflow. What conditions must the operand types satisfy? Or do I need to use @shlWithOverflow and check for overflow?

result |= u64(1) << u6(idx);

u6(x) no longer forces an integer cast. You'll have to use @intCast for that.

This is how I would write it:

test "error: expected type 'u6', found 'u64'" {
    var idx: u6 = 0;
    var result: u64 = 0;
    while (true) : (idx += 1) {
        result |= u64(1) << idx;
        if (idx == 63) break;
    }
}

Edit: or like this ;)
var result: u64 = @import("std").math.maxInt(u64);

Another one

test "error: expected type 'u6', found 'u64'" {
    const result = comptime x: {
        var idx = 0;
        var result = 0;
        while (idx < 64) : (idx += 1) {
            result |= 1 << idx;
        }
        break :x result;
    };
}

Thank you. That works! Here is what I came up with, maybe slightly more concise:

test "works" {
    var idx: u6 = 0;
    var result: u64 = 0;
    while (idx <= 63) : (idx += 1) {
        result |= u64(1) << idx;
    }
}

your example does this for me in debug mode:

Test 1/1 works...integer overflow
/home/andy/downloads/zig/build/test.zig:4:30: 0x2050b0 in ??? (test)
    while (idx <= 63) : (idx += 1) {
                             ^
/home/andy/downloads/zig/build/lib/zig/std/special/test_runner.zig:13:25: 0x2231fa in ??? (test)
        if (test_fn.func()) |_| {
                        ^
/home/andy/downloads/zig/build/lib/zig/std/special/bootstrap.zig:112:22: 0x222eb3 in ??? (test)
            root.main() catch |err| {
                     ^
/home/andy/downloads/zig/build/lib/zig/std/special/bootstrap.zig:49:5: 0x222c70 in ??? (test)
    @noInlineCall(posixCallMainAndExit);
    ^

Tests failed. Use the following command to reproduce the failure:
/home/andy/downloads/zig/build/zig-cache/test

A u6 is always less than or equal to 63, so that's equivalent to while (true)

Oops off by one. Strange that I didn't see an error on windows. Anyway. Thank you.

By the way, the rules about integer types with regards to shifting are not arbitrary. Zig is protecting against undefined behavior here. In C it's actually pretty easy to accidentally invoke undefined behavior by shifting by a number of bits equal to the LHS integer size. The simplest way to shift is probably to just @intCast the RHS to the correct type, which inserts a safety check in debug mode to make sure the value is in range.

Oic, nevermind, I was ignoring some other compiler errors and the test was never running.

I like that behavior. I really like where the language is going.