Implement @typeId
#19861
Implement @typeId
#19861
Conversation
|
OK noted. I will prioritize that proposal since you opened this PR. |
|
|
||
| const ty = try sema.resolveType(block, ty_src, extra.operand); | ||
|
|
||
| return sema.mod.intRef(Type.u32, @intFromEnum(ty.ip_index)); |
There was a problem hiding this comment.
Is this a comptime value? Will this be stable across compiler runs?
There was a problem hiding this comment.
Yes, it is a comptime value. I believe it will be stable across compiler runs with this implementation (as long as you're compiling the same source with the same options), but a proposal will have to figure out whether or not the @typeIds should even be the same across runs, and if so, how.
(The current implementation is of course not guaranteed to produce the same @typeIds as the compiler becomes parallelized.)
There was a problem hiding this comment.
If its comptime then it will need to be stable across all compiler runs ever, because again we'd have nondeterminism in the language. If its runtime, this can be side stepped and made implementation-defined behavior (because it only needs to be stable across compiler runs & it can change across versions).
Maybe this seems like an arbitrary distinguishment, but I think it's right that returning an undefined value at runtime is fine.
|
With the ongoing parallelization of the compiler it would be nice if there was some test that the ID remains stable across compilations to avoid nondeterministic builds. |
|
draft status, no updates in 30+ days |
|
Proposal was rejected |
Implementation for #19858 if approved. Uses the
InternPool.Index, but can be modified to not expose theInternPool.Indexvia aAutoArrayHashMapUnmanaged(InternPool.Index, void)for example.