Make `@ptrToInt` on address of comptime variable an error

[Vexu]

This is in direct contradiction to parts of #9646 and these two test cases https://github.com/ziglang/zig/blob/master/test/behavior/comptime_memory.zig#L319-L371. As discussed in the self hosted compiler meetings the justification for this is change is that it seems like a lot of work for little value and making it an error also avoids the complications brought by comptime only types.

cc @SpexGuy

Closes #11211

[SpexGuy]

Shoot, I shouldn't have missed the meeting 😅 @ptrToInt at comptime is something that sort of needs to work. Without it, there's a pretty strange line for what compiles and what doesn't. For example, code which does a direct ptrCast from *T to [*]u8 in order to offset a pointer would be fine at comptime, but code which uses @ptrToInt and adds a byte offset would not.

Additionally, you aren't really saving any complexity. This code is still well defined:

pub fn betterPtrToInt(comptime ptr: anytype) usize {
    return @ptrCast(*const usize, &ptr).*;
}

[Vexu]

@ptrToInt at comptime is something that sort of needs to work. Without it, there's a pretty strange line for what compiles and what doesn't. For example, code which does a direct ptrCast from *T to [*]u8 in order to offset a pointer would be fine at comptime, but code which uses @ptrToInt and adds a byte offset would not.

The things that can be done with @ptrCast are more limited and guaranteed to stay within the original allocation. Is @ptrToInt(&a) + 1 guaranteed to not overflow? What's stopping @ptrToInt from returning std.math.maxInt(usize)?

Additionally, you aren't really saving any complexity. This code is still well defined:

This can easily be made to have an error like reinterpreting pointers to comptime variables is not allowed or something. What does this code do?

test {
    comptime var a = 1;
    comptime @compileLog(betterPtrToInt(&a));
}

[eLeCtrOssSnake]

This is in direct contradiction to parts of #9646 and these two test cases https://github.com/ziglang/zig/blob/master/test/behavior/comptime_memory.zig#L319-L371. As discussed in the self hosted compiler meetings the justification for this is change is that it seems like a lot of work for little value and making it an error also avoids the complications brought by comptime only types.

cc @SpexGuy

Closes #11211

This features should exist. There is no justification for removing it. Inspecting own PE Header for example is one reason. Getting PEB on Windows requires a hard coded address.

[Vexu]

This features should exist. There is no justification for removing it. Inspecting own PE Header for example is one reason. Getting PEB on Windows requires a hard coded address.

I don't understand what you're trying to say.

[andrewrk]

@Vexu if you wouldn't mind rebasing this and getting the CI checks passing, I'll prioritize accepting it / rejecting it. I'm leaning towards accepting it, and amending the spec, as long as it doesn't break any valuable use case.

[eLeCtrOssSnake]

This features should exist. There is no justification for removing it. Inspecting own PE Header for example is one reason. Getting PEB on Windows requires a hard coded address.

I don't understand what you're trying to say.

I confused myself on that one. I agree, in comptime it's hard to understand what compiler might come up with, so removing @ptrToInt for comptime variables makes sense to not allow "C hacks" in comptime. The only use case I am a bit worried about is negative indexing from pointer, I am not sure how useful it is, but it might be a point for consideration as zig does not allow negative array index, so the only real way to do it is through pointer math(but negative indexing is kind of bad anyway). Again, not sure if it's a useful thing in comptime, more of a real code(not comptime) C interaction thing. I am not thinking of any other use case for comptime pointer math as there are better alternatives with for/while loops, many item ptr's etc. All in all I think it makes sense.

[Vexu]

The current behavior of @ptrToInt of only evaluating at comptime if the pointer value has a comptime representation is more in line with the rest of the language (currently) and solves the problem I originally had. I implemented reinterpreting pointers to declarations to also become runtime operations to completely solve the issue for now.

Whether this should be a compile error can be decided when solving #2471 as far as I'm concerned.