stage2: cannot determine length of array in comptime block

[ominitay]

Zig Version

0.10.0-dev.3313+cff5d9c80 (stage2)

Steps to Reproduce

Attempt to compile one of the following examples:

var bytes: [1024]u8 = undefined;

export const length = bytes.len;

var bytes: [1024]u8 = undefined;

comptime { _ = bytes.len; }

Expected Behavior

The examples compile successfully (or, more accurately, errors out because there's no main function).

Actual Behavior

The examples both reach a compile error, of the form:

test.zig:3:23: error: cannot load runtime value in comptime block
export const length = bytes.len;
                      ^~~~~~~~~~~

Hint: The following examples do not reach a compile error:

const bytes: [1024]u8 = undefined;

export const length = bytes.len;

var bytes: [1024]u8 = undefined;

test { comptime _ = bytes.len; }

[ominitay]

Thank you @topolarity for helping to reduce this!

[andrewrk]

Related:

• #12215
• #12638

Compile error is emitted on the decl_val before it has a chance to look at the len field:

    > %9 = decl_val("bytes") 
      %10 = field_val(%9, "len") 

Resolution is unclear. Will require some reworking of AstGen/ZIR with regards to the decl_val instruction.

[Vexu]

I tried solving this in AstGen today and while I was able to get all the examples in the issue working it is still easy to break for example by adding a cast @as([1024u8, bytes). Maybe it'd be better to allow runtime instructions in outside of function bodies and rely on other mechanisms to get comptime known where they are needed as stage1 seems to be doing.

This approach could also result in better compile errors by turning the error in:

var cc: std.builtin.CallingConvention = .C;
export fn foo() callconv(cc) void {}

from

error: cannot load runtime value in comptime block
export fn foo() callconv(cc) void {}
                         ^~

to

error: unable to resolve comptime value
export fn foo() callconv(cc) void {}
                         ^~
note: calling convention must be comptime-known

[nektro]

bytes.len should be comptime known though, the issue is that there's any error at all

doing @as in a comptime scope shouldn't change that

[Vexu]

bytes.len should be comptime known though, the issue is that there's any error at all

Yes but bytes is not comptime known and Zir works by first loading bytes and then doing field access on that.

doing @as in a comptime scope shouldn't change that

That's why I said that my AstGen based solution isn't that good.