Repository navigation
inline tail call does not honor comptime semantics #12108
Description
Zig Version: 0.10.0-dev.2992+1fee9eac8
test "inline tail call" {
if (!foo()) {
@compileError("expected a comptime value");
}
}
inline fn foo() bool {
return bar();
}
inline fn bar() bool {
return true;
}Should pass, however, the result of foo() ends up being runtime-known:
$ stage2/bin/zig test test3.zig
test3.zig:10:9: error: expected a comptime value
@compileError("expected a comptime value");
^
Problem disappears if foo is rewritten like this:
inline fn foo() bool {
const result = bar();
return result;
}
Activity
nektro commentedon Jul 14, 2022
doesnt pass on stage1 either. is this a new feature of
inline fns being eagerly evaluated?andrewrk commentedon Jul 20, 2022
Yes it's new
inlinesemantics that are going into the language specification. Function inlining happens during semantic analysis, meaning that if an inlined function returns a comptime-known value, it is comptime-known at the callsite.It also makes recursive inline functions work as long as they don't recurse too many times.
tauoverpi commentedon Aug 31, 2023
With the new behaviour, would
inline fn assert(ok: bool) voidmake more sense than the current implementation given that the condition may be comptime known and thus all code following it can be deleted (replaced by panic or a return in release-fast/small)?mlugg commentedon Sep 15, 2023
Appears to be fixed in master.