Skip to content

Crash iterating over tuple elements via pointer in comptime #19428

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
michaelbartnett opened this issue Mar 24, 2024 · 3 comments
Closed

Crash iterating over tuple elements via pointer in comptime #19428

michaelbartnett opened this issue Mar 24, 2024 · 3 comments
Labels
bug Observed behavior contradicts documented or intended behavior

Comments

@michaelbartnett
Copy link
Contributor

michaelbartnett commented Mar 24, 2024

Zig Version

0.12.0-dev.3434+e90583f5d

Steps to Reproduce and Observed Behavior

This code produces a compiler crash on master:

const std = @import("std");

pub const attributes = struct {
    pub fn first(comptime T: type, comptime AttribType: type) ?*const AttribType {
        inline for (&T.ATTRIBUTES) |*attrib| {
            if (comptime @TypeOf(attrib.*) == AttribType) {
                return attrib;
            }
        }
        return null;
    }
};

pub const SimpleAttribute = struct {
    n: i32,
};

pub const SomeTypeWithAttributes = struct {
    m: u8 = 255,

    pub const ATTRIBUTES = .{
        SimpleAttribute{ .n = 42 },
    };
};

pub fn main() void {
    var value: i32 = -1;
    if (attributes.first(SomeTypeWithAttributes, SimpleAttribute)) |pattr| {
        value = pattr.n;
    }

    std.log.info("SimpleAttribute.n of SomeTypeWithAttributes resolved to {}", .{value});
}

Expected Behavior

Expected no crash ofc :)

I also expect it to return the address of the element of the tuple declared in SomeTypeWithAttributes.

Squirl (🙌) on the discord pointed out that changing this function to return values instead of addresses gets rid of the crash, and that if I wanted to avoid making a bunch of copies I could still take the address of the comptime result value and it would likely dedupe.

This totally works for my current use case, although this leaves it in a less-semantically-clear state from the user's perspective. If I take the address of the result of the comptime function call result, is it the address of SomeTypeWithAttributes.ATTRIBUTES[0] or is it the address of a copy of that static data at a different location in memory at runtime? If that's not information that Zig wants to expose to the programmer, then maybe worth a compiler message or a note in docs?

@michaelbartnett michaelbartnett added the bug Observed behavior contradicts documented or intended behavior label Mar 24, 2024
@Vexu
Copy link
Member

Vexu commented Mar 25, 2024

Duplicate of #12963

@Vexu Vexu marked this as a duplicate of #12963 Mar 25, 2024
@Vexu Vexu closed this as not planned Won't fix, can't repro, duplicate, stale Mar 25, 2024
@Vexu
Copy link
Member

Vexu commented Mar 25, 2024

And to answer your question I would guess it to be a different address, you'll have to look at the pointers to know for sure.

@Vexu
Copy link
Member

Vexu commented Mar 26, 2024

With #19414 you can get this to work by just marking first inline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior
Projects
None yet
Development

No branches or pull requests

2 participants