Open DaanVandenBosch opened 1 year ago
Pretty sure this is a direct result of #16072 .
Note that the sentinel-terminated slicing syntax x[a .. b :c]
asserts the sentinel of a slice (or array) is already present in-place - it doesn't change or provide that sentinel. Therefore:
c
at index b
of x.len
is (the way I understand it) accessing the slice (or array) out-of-bounds.
This is illegal behavior. (=> should be a compile error, as is the case in your example, or a runtime panic)c
is present fails. This is also illegal behavior.c
, the operation yields a pointer to array or a slice terminated by c
.
(=> With regard to the sentinel value, this is a no-op.)Once #16072 is fixed, simply using field.name
directly (or via const n = field.name;
) should already work.
As a workaround until then, you need to copy the contents over into a one-byte-larger new buffer.
Playing around with this I didn't find a convenient way to convert a length n+1
array into a sentinel-terminated length n
array via the type system currently.
Maybe someone else knows a shorter way; if not, that's probably an area for potential language improvements.
This is what I came up with:
// use as addZ(slice.len, slice[0..].*) - slice must be comptime-known
pub fn addZ(comptime length: usize, value: [length]u8) [length:0]u8 {
var terminated_value: [length:0]u8 = undefined;
terminated_value[length] = 0;
@memcpy(&terminated_value, &value);
return terminated_value;
}
The original error output pointing to file location :1:1
looks like a separate bug in compile error generation logic that should be fixed as well though.
That wasn't clear to me, but I see the documentation directly states it. Thanks for pointing it out, figuring out the real problem and giving me a workaround!
The error message is confusing though. Following your explanation, I understand where this "low level" message comes from, but a clearer, more high level message would be nice.
Zig Version
0.11.0-dev.3724+32cb9462f
Steps to Reproduce and Observed Behavior
zig run
the following code:Output:
The line marked with a comment seems to be the problematic line because the field name length is 9 and changing the slice conversion to
[0..field.name.len :0]
gives a similar error but now the position of the error is a bit more sensible:If it helps, the actual code from which this was simplified worked with zig from a week or two ago (don't know the exact date, I deleted the previous version of zig before installing a newer version, have learned my lesson ;-)).
Expected Behavior
The code should simply compile and run, printing "Field name: someField".