Cannot evaluate @ptrToInt at comptime

[lovely-error]

Zig Version

0.11.0-dev.2194+626a75bbc

Steps to Reproduce and Observed Behavior

When building a file containing this code...

const std = @import("std");

fn c () void {}

const b = @ptrToInt(&c);

pub fn main () void {
    std.debug.print("{}", .{b});
}

... with this parameters...

zig build-exe f.zig

... I get the following error...

f.zig:40:11: error: unable to evaluate comptime expression
const b = @ptrToInt(&c);
          ^~~~~~~~~~~~~
f.zig:40:21: note: operation is runtime due to this operand
const b = @ptrToInt(&c);

This does not seem right to me, since it is okay to take a function address and print in main. For some reason the compiler is unable to understand a slightly more compilcated arrangement of things. Why is that, I wonder?

Expected Behavior

Should work just fine.

[mlugg]

Initialization expressions of global variables are evaluated at comptime (this is in contrast to languages like C++, where they're evaluated at runtime when your program starts). @ptrToInt currently doesn't work at comptime, because comptime evaluation happens wayyy before anything's actually been placed in the binary.

In future, it's intended for this to work, by making @ptrToInt return a "lazy" value at comptime which can be replaced with a relocation later. I don't think there's currently an issue to track that feature, so this issue could become that: maybe rename it to cannot evaluate @ptrToInt at comptime?

[lovely-error]

Understood, thank you for explanation. Renaming now.

[dvmason]

Initialization expressions of global variables are evaluated at comptime (this is in contrast to languages like C++, where they're evaluated at runtime when your program starts). @ptrToInt currently doesn't work at comptime, because comptime evaluation happens wayyy before anything's actually been placed in the binary.

In future, it's intended for this to work, by making @ptrToInt return a "lazy" value at comptime which can be replaced with a relocation later. I don't think there's currently an issue to track that feature, so this issue could become that: maybe rename it to cannot evaluate @ptrToInt at comptime?

I wonder if this is thinking about this correctly... or perhaps that is me. :-)

As far as I understand, @ptrToInt is not calculating anything at runtime or compile time... it is simply changing the type associated with a value. I guess, perhaps, that the now-usize type might need a tag to say that it's derived from an address so that a subsequent operation like @truncate or even + would give an error.

I filed a duplicate bug as #15884 because the search didn't turn up this one.

[rohlem]

The builtin's name has been changed to @intFromPtr, so we might want to update the title. The underlying issue still behaves the same in version 0.14.0-dev.2371+c013f45ad.