You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test {
comptimevarfoo: u32=0;
_=bar({
foo+=1;
});
@compileLog(foo);
}
fnbar(val: anytype) if (@TypeOf(val) ==void) comptime_intelseu32 {
return123;
}
$ zig test foo.zig
foo.zig:6:5: error: found compile log statement
@compileLog(foo);
^~~~~~~~~~~~~~~~
Compile Log Output:
@as(u32, 2)
Expected Behavior
The logged value should be 1, because the argument expression should only be evaluated once.
This happens because:
Sema.analyzeCall notices that we are calling a generic function, so calls Sema.instantiateGenericCall
After evaluating the arguments, instantiateGenericCall notices that the resolved return type is comptime-only, so returns error.ComptimeReturn
Sema.analyzeCall catches this and performs a comptime call instead
This code path re-evaluates the arguments
To fix this, the resolved argument values must be cached after they are first analyzed; perhaps by CallArgsInfo itself, or perhaps through some specialized mechanism between analyzeCall and instantiateGenericCall.
The text was updated successfully, but these errors were encountered:
mlugg
added
the
bug
Observed behavior contradicts documented or intended behavior
label
Dec 17, 2024
mlugg
changed the title
Parameters are evaluated multiple times when a function return type turns out to be comptime-only
Parameters are evaluated multiple times when a generic return type turns out to be comptime-only
Dec 17, 2024
Zig Version
0.14.0-dev.2443+3f7b3daaa
Steps to Reproduce and Observed Behavior
Expected Behavior
The logged value should be
1
, because the argument expression should only be evaluated once.This happens because:
Sema.analyzeCall
notices that we are calling a generic function, so callsSema.instantiateGenericCall
instantiateGenericCall
notices that the resolved return type is comptime-only, so returnserror.ComptimeReturn
Sema.analyzeCall
catches this and performs a comptime call insteadTo fix this, the resolved argument values must be cached after they are first analyzed; perhaps by
CallArgsInfo
itself, or perhaps through some specialized mechanism betweenanalyzeCall
andinstantiateGenericCall
.The text was updated successfully, but these errors were encountered: