`@intFromPtr` at `comptime` has misleading error message

[rohlem]

Zig Version

0.14.0-dev.2371+c013f45ad

Steps to Reproduce and Observed Output

Current reproduction:

comptime {
    const x: u8 = 0;
    _ = @intFromPtr(&x);
}

Current compile error output:

.zig:3:9: error: unable to evaluate comptime expression
    _ = @intFromPtr(&x);
        ^~~~~~~~~~~~~~~
.zig:3:21: note: operation is runtime due to this operand
    _ = @intFromPtr(&x);
                    ^~

The note is somewhat misleading, because nothing about this operand is runtime.
It seems to me like the error note logic was copied from some other operation without much thought.
What's actually happening is that @intFromPtr itself is currently restricted to runtime contexts.
(See #15080, the plan is to eventually implement workaround semantics for comptime.)

Expected Output

Something along the lines of:

.zig:3:9: error: unable to evaluate comptime expression
    _ = @intFromPtr(&x);
        ^~~~~~~~~~~~~~~
.zig:3:21: note: @intFromPtr is currently only available at runtime

[mlugg]

nothing about this operand is runtime

There is: its address isn't known until runtime. This is different to a pointer which comes from @ptrFromInt, which has a comptime-known address, and hence can have @intFromPtr used on it at comptime.

However, I agree that this error message could be improved, so will leave this issue open.

[rohlem]

nothing about this operand is runtime

There is: its address isn't known until runtime.

That might be true in a general case, which is probably how it's currently analyzed.
In the given example, x is declared as a const inside a comptime block.
The comptime block and x are both comptime-only, so they don't even exist at / persist until runtime.

EDIT2: Wait, I think I see what you mean, const in comptime scopes are still lowered to global constants if runtime code depends on them.
So x will still be assigned a final runtime-accessible location (even though it is unused here and could be optimized out),
and the address of that location would probably be determined at a later stage, therefore not be available in comptime logic.
(That's a tricky detail, awkward not to have syntax/vocabulary for comptime-ephemeral things.)

EDIT3: For what it's worth, when replacing const x with var x, it should never be associated with a runtime-accessible location, yet leads to the same error message currently.

This is different to a pointer which comes from @ptrFromInt

You're right, I must have made a mistake when testing that before, @intFromPtr(@as(*u8, @ptrFromInt(1))) correctly works already.

[rohlem]

So x will still be assigned a final runtime-accessible location (even though it is unused here and could be optimized out) [...].
(That's a tricky detail, awkward not to have syntax/vocabulary for comptime-ephemeral things.)

Bit of a tangent, but thinking about this some more, the language actually already provides
a distinct way to mark a value as persistent until runtime by assigning it to a container-scope declaration:
(opaque {const persistent_x = x;}).persistent_x
Given this, it seems to me like the status-quo behavior of allowing the address of a comptime stack const to escape is unnecessary/redundant.
Any value that should be accessible at runtime can instead be copied into a container declaration.
This would fully align local const lifetime in runtime and comptime scopes.

If I remember correctly last the big changes regarding comptime references were #19414 and #19630, however I couldn't find discussion about removing this behavior.
Would this be worth opening a new issue/proposal about?