Do not run asserts for WASI alignment when not targeting WASI

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.

[190n]

Fixes#19665

It seems possible that the last two asserts should now be uncommented as well. I don't know enough about why they were commented in the first place.

[nektro]

how is the file getting referenced in a non-wasi build?

[190n]

I think this is at least one of the culprits:

zig/lib/std/std.zig

Lines 115 to 119 in e69caaa

	pubconstOptions=struct {
	enable_segfault_handler: bool=debug.default_enable_segfault_handler,
	/// Function used to implement `std.fs.cwd` for WASI.
	wasiCwd: fn () os.wasi.fd_t=fs.defaultWasiCwd,

I had a reproduction in #19919, although I closed that issue since I didn't realize it was a duplicate of #19665. The issue went away for me when I removed a call to std.log, which was indirectly using my Options struct.

[190n]

Tests still pass locally with the i64/u64 alignment checks enabled, including x86-linux which seems to be the original reason they got disabled, so I'm pushing that change as well.

[nektro]

I'd recommend changing std.options.wasiCwd to be a void on non-wasi rather than editing the wasi file. files named for a target shouldn't have to worry about not being on that target, the bug imo is the spillage causing that to be evaluated.

[190n]

Oh, that's failing on 32-bit x86 again. It must be referenced somewhere else too.

[190n]

It seems like a few WASI-specific functions in std.posix get analyzed on all targets, and they reference WASI types in their signatures/returns. e.g. (targeting x86):

error: the following command failed with 1 compilation errors:
/home/ben/zig/build/stage4/bin/zig test -freference-trace=256 -ODebug -target x86-linux-gnu -mcpu baseline -Mroot=/home/ben/zig/lib/std/std.zig -lc --test-filter std-wasm32-wasi.0.1...0.1-musl-generic-Debug-libc --cache-dir /home/ben/zig/zig-cache --global-cache-dir /home/ben/.cache/zig --name test --zig-lib-dir /home/ben/zig/lib --listen=- test-std
└─ run test std-wasm32-wasi.0.1...0.1-musl-generic-Debug
└─ zig test Debug wasm32-wasi 1 errors
/home/ben/zig/lib/std/posix.zig:1659:5: error: found compile log statement
@compileLog("openatWasi");
^~~~~~~~~~~~~~~~~~~~~~~~~

Should we

• make all these params conditional on builtin.os.tag (and I'm not sure if this is the only place causing such issues, as -freference-trace isn't being very helpful)?
• move these all into a module that's only called on WASI?
• switch back to checking the OS inside std/os/wasi.zig?
• something else?

[Vexu]

• switch back to checking the OS inside std/os/wasi.zig?

Like I said in the issue #19665 (comment)

[190n]

Yeah, that seems probably easier at this point. I wanted to try @nektro's option but it seems like there are a lot more WASI references throughout std and it'll be hard to find them all.