LLVM backend hits `unreachable` lowering pointer to comptime field

[omaraaa]

Zig Version

0.10.0-dev.4060+61aaef0b0

Steps to Reproduce

const std = @import("std");

test {
    const T = std.meta.Tuple(&.{struct {}});
    var t: T = undefined;
    inline for (std.meta.fields(T)) |f| {
        var ptr = &@field(t, f.name);
        _ = ptr;
    }
}

Expected Behavior

All 1 tests passed.

Actual Behavior

error: TODO (LLVM): implement const of pointer type '[TODO fix internal compiler bug regarding dump]' (value.Value.Tag.comptime_field_ptr)

[nektro]

expected behavior is multiple compile errors

[omaraaa]

expected behavior is multiple compile errors

What would the compile errors be? The code compiles and passes in stage 1.

[omaraaa]

Another variation:

const std = @import("std");

test {
    const T = std.meta.Tuple(&[_]type{struct {}});
    var t: T = undefined;
    var ptr = &t.@"0";
    _ = ptr;
}

It seems to me that getting a pointer to a zero-sized field is the problem.

[Vexu]

This is not specific to tuples:

const std = @import("std");

test {
    const T = struct {
        comptime a: struct{} = .{},
    };
    var t: T = undefined;
    inline for (std.meta.fields(T)) |f| {
        var ptr = &@field(t, f.name);
        _ = ptr;
    }
}

[omaraaa]

This is not specific to tuples:

const std = @import("std");

test {
    const T = struct {
        comptime a: struct{} = .{},
    };
    var t: T = undefined;
    inline for (std.meta.fields(T)) |f| {
        var ptr = &@field(t, f.name);
        _ = ptr;
    }
}

This seems like a separate issue that is hitting the same TODO. It should produce a compile error that you can't use T in a runtime context...but it doesn't.

The main issue with tuples/anonStructs is that the logic for zero-sized field pointers in sema is flawed. In tupleFieldPtr:

• It checks if the value of a field is comptime.
• Zero-sized fields are comptime since they have zero runtime bits
• Thus it outputs a comptime_field_ptr for zero-sized field pointers!

#12977 fixed tuples/@Type zero-sized field pointers for me.

[Vexu]

It should produce a compile error that you can't use T in a runtime context...but it doesn't.

Sure you can, all the operations on them just end up being comptime known since they can only have one possible value.

• Zero-sized fields are comptime since they have zero runtime bits

Zero-sized fields are comptime since they have only one possible value which is know at comptime.

I think the correct solution is to generate comptime_field_ptrs as undefined pointers.

[omaraaa]

Zero-sized fields are comptime since they have only one possible value which is know at comptime.

Yes, for values. But shouldn't a pointer to field have a runtime value, even if it's zero-sized?

const Foo = struct {
  a: struct{} = .{},
};

// This is fine in stage1 and stage2, no comptime_field_ptr
var foo: Foo = .{};
var ptr = &foo.a;
_ = ptr;

//This doesn't work in stage2, produces comptime_field_ptr
const T = std.meta.Tuple(&[_]type{struct {}});
var t: T = .{ .@"0" = .{} };
var ptr2 = &t.@"0";
_ = ptr2;

Both are essentially the same, but the first example works while the other doesn't.

edit: I suspect that:

• In 'structFieldPtrByIndex`, 'field.is_comptime' is used to check if the field is comptime.
  • field.is_comptime returns false for zero-sized fields that are not comptime.
• While in tupleFieldPtr, field_val.tag() != .unreachable_value is used.
  • field_val.tag() != .unreachable_value returns true for zero-sized fields, since a zero-sized field is knowable in comptime.

I think the correct solution is to generate comptime_field_ptrs as undefined pointers.

From what I understood, comptime_field_ptrs should never reach llvm. If is does then there is something wrong in sema.
But I'm not familiar with Zig's codebase, so I might be wrong.

[Vexu]

This is also not specific to zero-bit types:

test {
    const T = struct {
        comptime a: u32 = 2,
    };
    var t: T = undefined;
    var ptr = &t.a;
    _ = ptr;
}

From what I understood, comptime_field_ptrs should never reach llvm.

Pointers to comptime fields should behave same as pointers to container-level variables so that above example should behave same as:

test {
    const T = struct {
        var a: u32 = 2;
    };
    var ptr = &T.a;
    _ = ptr;
}

[omaraaa]

Oh, so stage2 allows structs with comptime fields to be a runtime variable. Didn't know that.

I think the correct solution is to generate comptime_field_ptrs as undefined pointers.

Will this mean that @fieldParentPtr will not work for zero-sized fields?

[Vexu]

Oh, so stage2 allows structs with comptime fields to be a runtime variable. Didn't know that.

That has always been allowed, I think you might be confusing comptime fields with fields with comptime only types:

const S = struct {
    // comptime field
    comptime a: i32 = 2,
    // field with a comptime only type
    b: comptime_int,
};

The key difference is that comptime fields are tied to the type while fields with comptime only types are tied to an instance.

Will this mean that @fieldParentPtr will not work for zero-sized fields?

No, but it does mean that @fieldParentPtr should disallow comptime fields which is a missing compile error, and that for tuples you'll have to construct the type using @Type since the regular syntax does not support making runtime zero-bit fields.