sema: add compile error for OOB by-length slice of array

[dweiller]

Fixes #18382.

This change introduces a compile error when a by-length (i.e. buf[a..][0..len]) slice of an array with length comptime-known to be less than len is performed. Previously this case would compile and not even insert a runtime safety check in safe build modes.

An example of the new compile error is:

failing.zig:6:23: error: length 5 array cannot be sliced to length 10
    _ = slice[a..][0..10];
                      ^~

which is generated by this test:

test {
    var buf: [5]u8 = undefined;
    const slice = &buf;
    var a: u32 = 6;
    _ = &a;
    _ = slice[a..][0..10];
}

[Rexicon226]

could you add a test case for the double runtime case?

i.e

test {
    var buf: [5]u8 = undefined;
    const slice = &buf;
    var a: u32 = 6;
    _ = &a;
    _ = buf[a..][0..a];
    _ = slice[a..][0..a];
}

[dweiller]

I'm not sure about the workaround I've added in lib/std/json/static.zig to prevent the compile error being hit. I'm not familiar with the new json parser and not 100% sure that these situations are in fact unreachable - but it did get the tests passing for me locally. The other option would be to return error.LengthMismatch rather than hitting unreachable. Some input from @thejoshwolfe would be appreciated.

[thejoshwolfe]

just a small fix suggestion, otherwise looks good from me.

[dweiller]

could you add a test case for the double runtime case?

i.e

test {
    var buf: [5]u8 = undefined;
    const slice = &buf;
    var a: u32 = 6;
    _ = &a;
    _ = buf[a..][0..a];
    _ = slice[a..][0..a];
}

Done.

[andrewrk]

Reverted in bd46410.

[dweiller]

Reverted in bd46410.

Would you rather a runtime safety check? I don't think it will be possible to have a compile error to prevent out-of-bounds length slicing without either the kind of workaround that was introduced in std.json, or much more sophisticated comptime analysis of integers/integer ranges.

[andrewrk]

Yes, it should emit a compile error if illegal behavior is detected at compile-time. There must be no false positives (the problem of this implementation). If it cannot be detected at compile-time correctly then it should be detected at runtime.

[dweiller]

Yes, it should emit a compile error if illegal behavior is detected at compile-time. There must be no false positives (the problem of this implementation). If it cannot be detected at compile-time correctly then it should be detected at runtime.

The analogous compile error for slicing an array normally (i.e. not 'by-length') has the same kind of false-positive, i.e. this test:

test {
    const array = [_]u8{ 0, 1, 2, 3, 4, 5 };
    var start: usize = 0;
    _ = &start;
    const end = array.len + 1;
    if (start + end < start + array.len) {
        _ = array[start..end];
    }
}

results in

t.zig:7:26: error: end index 7 out of bounds for array of length 6
        _ = array[start..end];
                         ^~~

despite never attempting an out-of-bounds access. Should this compile error also be moved to a runtime check?