[0..0], [0..1], [1..1] slicing on *OpaqueType or *const OpaqueType values is allowed now #35880

Zig Version

0.17.0-dev.813+2153f8143

Steps to Reproduce, Observed Behavior, and Expected Behavior

The following code compiles okay, but should it?
The *const [1]anyopaque type is an illegal type in Zig.

constprint=@import("std").debug.print;pubfnmain()void{constv:u8=123;constp:*constanyopaque=&v;consts=p[0..1];// compiles okay, but a bug?print("{}\n",.{@TypeOf(s)});// *const [1]anyopaque// _ = s[0]; // make compilation "Segmentation fault" if enabled}

$ vim test.zig
$ zig-master run test.zig 
*const [1]anyopaque
$ zig-0.16.0 run test.zig 
*const [1]anyopaque
$ zig-0.15.0 run test.zig 
*const [1]anyopaque
$ zig-0.14.0 run test.zig 
*const [1]anyopaque
$ zig-0.13.0 run test.zig 
*const [1]anyopaque
$ zig-0.12.0 run test.zig 
*const [1]anyopaque
$ zig-0.11.0 run test.zig 
test.zig:6:16: error: slice of single-item pointer
 const s = p[0..1]; // compiles okay, but a bug?
 ~^~~~~~

behavior is not a recent change/regression and since the slice length is only 1 it's okay that it does not know the stride length. if you change the end to 2 you do get an error like so:

$ zig-master run test.zig 
test.zig:6:20: error: slice of single-item pointer must have bounds [0..0], [0..1], or [1..1]
 const s = p[0..2]; // compiles okay, but a bug?
 ^
test.zig:6:20: note: expected '1', found '2'

related: https://github.com/ziglang/zig/issues/19806 (?)

more related to https://github.com/ziglang/zig/issues/16075

by my comment i meant i do not think this is a bug

The *const [1]anyopaque type is an illegal type in Zig.

can you clarify why you believe this to be the case?

If you enable the last line, the compiler crashes.

@nektro this is definitely a bug---you can't have an array of anyopaque because anyopaque does not have a known size (the same goes for all opaque types). That's why simply writing _ = [1]anyopaque; is enough to trigger a compile error:

repro.zig:2:12: error: array of opaque type 'anyopaque' not allowed
 _ = [1]anyopaque;
 ^~~~~~~~~

@mlugg that makes sense for an array value, my comment was about a pointer-to-array

@Tapir apologies, i am able to reproduce now

Analyzing 'test.zig'
 %8 = dbg_stmt(2, 5)
 %9 = int(123)
 %10 = as_node(@u8_type, %9) node_offset:4:19 to :4:22
 %16 = ref(%10) token_offset:5:34 to :5:35
 %11 = validate_const(%10) node_offset:4:19 to :4:22
 %12 = dbg_var_val(%10, "v")
 %13 = dbg_stmt(3, 5)
 %14 = ptr_type(@anyopaque_type, const, one) node_offset:5:14 to :5:30
 %15 = validate_ref_ty(%14) token_offset:5:33 to :5:34
 %17 = as_node(%14, %16) node_offset:5:33 to :5:35
 %21 = ref(%17) token_offset:6:15 to :6:16
 %18 = validate_const(%17) node_offset:5:33 to :5:35
 %19 = dbg_var_val(%17, "p")
 %20 = dbg_stmt(4, 16)
 %22 = slice_end(%21, @zero, @one) node_offset:6:15 to :6:22
 %38 = ref(%22) token_offset:9:9 to :9:10
 %23 = validate_const(%22) node_offset:6:15 to :6:22
 %24 = dbg_var_val(%22, "s")
 %25 = dbg_stmt(5, 5)
 %26 = decl_val("print") token_offset:7:5 to :7:10
 %27 = dbg_stmt(5, 10)
 %28 = call(nodiscard .auto, %26, [
 {
 %29 = str("{}\n")
 %30 = break_inline(%28, %29)
 },
 {
 %31 = validate_array_init_result_ty(%28, 1) node_offset:7:19 to :7:34
 %32 = array_init_elem_type(%28, 0)
 %33 = typeof_builtin({
 %34 = break_inline(%33, %22)
 }) node_offset:7:22 to :7:32
 %35 = array_init(%28{%33}) node_offset:7:19 to :7:34
 %36 = break_inline(%28, %35)
 },
 ]) node_offset:7:5 to :7:35
 %37 = dbg_stmt(7, 10)
 > %39 = elem_ptr_load(%38, @zero) node_offset:9:9 to :9:13
 %40 = ensure_result_non_error(%39) node_offset:9:9 to :9:13
 %41 = restore_err_ret_index_unconditional(.none) node_offset:3:1 to :3:7
 %42 = ret_implicit(@void_value) token_offset:10:1 to :10:1

A pointer to an array of opaque types is still effectively a pointer to an opaque type, so I don't really see a point in allowing that. There's nothing you could do with a pointer to [N]anyopaque that you couldn't with a pointer to anyopaque since indexing into it is meaningless/not possible.
Just disallowing arrays of opaque types altogether is the simpler choice here language-wise.

@mlugg

you can't have an array of anyopaque because anyopaque does not have a known size

why should anyopaque's lack of a known size affect its ability to be put in an array? fn () void, comptime_int, and type, too, don't have a concrete size, yet putting them in array is very much fine. I'd expect an array of anyopaques to work just as well (arrays of noreturns too, while we're at it), and denote a unit type when the length is zero, an uninhabited type otherwise.

A pointer to an array of opaque types is still effectively a pointer to an opaque type,

the latter of which is already unambiguously valid and useful.
but beyond the size 1 it can not be indexed. i was+am not arguing *const [2]anyopaque should be valid.

is anyone able to get a stack trace for the crash? zig printed ?????? frames on this for me and running it in gdb oom'd my computer.

Here:

thread 3581471 panic: reached unreachable code
/home/david/Code/zig/src/Type.zig:1177:27: 0x2eb95d1 in abiSize (main.zig)
 .anyopaque => unreachable,
 ^
/home/david/Code/zig/src/Value.zig:1809:56: 0x416624b in ptrElem (main.zig)
 const byte_offset = field_idx * elem_ty.abiSize(zcu);
 ^
/home/david/Code/zig/src/Sema.zig:27547:56: 0x41edc85 in elemPtrArray (main.zig)
 return .fromValue(try array_ptr_val.ptrElem(index, pt));
 ^
/home/david/Code/zig/src/Sema.zig:27071:40: 0x45027fd in elemPtr (main.zig)
 .array => try sema.elemPtrArray(block, src, indexable_ptr_src, indexable_ptr, elem_index_src, elem_index, init, oob_safety),
 ^
/home/david/Code/zig/src/Sema.zig:27205:54: 0x46436f2 in elemVal (main.zig)
 const elem_ptr = try sema.elemPtr(block, indexable_src, indexable, elem_index, elem_index_src, false, oob_safety);
 ^
/home/david/Code/zig/src/Sema.zig:9590:27: 0x46426c8 in zirElemPtrLoad (main.zig)
 return elemVal(sema, block, src, array, uncoerced_elem_index, elem_index_src, true);
 ^
/home/david/Code/zig/src/Sema.zig:1199:69: 0x40aea7c in analyzeBodyInner (main.zig)
 .elem_ptr_load => try sema.zirElemPtrLoad(block, inst),
 ^
/home/david/Code/zig/src/Sema.zig:1050:26: 0x40546b1 in analyzeFnBody (main.zig)
 sema.analyzeBodyInner(block, body) catch |err| switch (err) {
 ^