Zig Version
0.12.0
Steps to Reproduce and Observed Behavior
Compile a small file using std.log for AVR:
// foo.zigconststd=@import("std");
externfnlogBackend(ptr: [*:0]constu8, len: usize) void;
pubfnlogFn(
comptimelevel: std.log.Level,
comptimescope: @Type(.EnumLiteral),
comptimeformat: []constu8,
args: anytype,
) void {
constlevel_prefix=comptimelevel.asText();
constprefix=comptimelevel_prefix++switch (scope) {
.default=>": ",
else=>" ("++@tagName(scope) ++"): ",
};
varbuf: [1024:0]u8=undefined;
conststring=std.fmt.bufPrintZ(&buf, prefix++format, args) catch&buf;
logBackend(string.ptr, string.len);
}
pubconststd_options=std.Options{
.logFn=logFn,
};
exportfnmeow() u16 {
std.log.info("meow called", .{});
return5;
}$ zig build-obj foo.zig -O ReleaseFast -target avr-freestanding -mcpu=atmega4809 -freference-trace
/usr/lib/zig/std/debug.zig:403:14: error: reached unreachable code
if (!ok) unreachable; // assertion failure
^~~~~~~~~~~
/usr/lib/zig/std/os/wasi.zig:12:11: note: called from here
assert(@alignOf(i16) == 2);
~~~~~~^~~~~~~~~~~~~~~~~~~~
This assertion fails since apparently i16 is 1 byte aligned on AVR.
If I remove only the std.log.info line, it compiles fine.
Expected Behavior
I expect this file to compile without issues, since I provided a backend for std.log which doesn't need any OS support. It seems std.os.wasi is getting referenced by the definition of std.Options, as that uses os.wasi.fd_t:
wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,
It seems like I can fix this by changing that definition to have the type void on non-WASM targets, but I'm not 100% confident that doesn't break anything else. I can PR that change if desired.
Zig Version
0.12.0
Steps to Reproduce and Observed Behavior
Compile a small file using std.log for AVR:
This assertion fails since apparently i16 is 1 byte aligned on AVR.
If I remove only the
std.log.infoline, it compiles fine.Expected Behavior
I expect this file to compile without issues, since I provided a backend for std.log which doesn't need any OS support. It seems
std.os.wasiis getting referenced by the definition ofstd.Options, as that usesos.wasi.fd_t:It seems like I can fix this by changing that definition to have the type
voidon non-WASM targets, but I'm not 100% confident that doesn't break anything else. I can PR that change if desired.