Closed TerrorJack closed 2 years ago
GHC doesn't support WebAssembly, does it? Is this a new effort for GHC, or some other Haskell compiler? I'd like to be able to test this if possible.
It's a part of the work in adding WebAssembly support to GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7632
There aren't instructions to build that branch yet, but the change included here can be validated on CI for normal architecture.
Could you point me to the headers that define clockid_t
and CLOCK_REALTIME
in wasi-libc? I'd like to have a better idea of what's going on.
Of course:
struct __clockid
is defined at https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/cloudlibc/src/common/clock.h, with comment that explains why it's an object instead of an integer literal like other POSIX platformsclockid_t
is defined as a pointer to struct __clockid
at https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/__typedef_clockid_t.h. It's the public interface for wasi-libc
users.CLOCK_REALTIME
points to a global struct _CLOCK_REALTIME
at https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/__header_time.h_CLOCK_REALTIME
struct is defined at https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/cloudlibc/src/libc/time/CLOCK_REALTIME.c.__WASI_CLOCKID_REALTIME
magic number comes from https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/wasi/api.h#L79, which is automatically derived from the WASI spec fileOverall, clockid_t
can't be an integer literal that can be detected as hsc2hs #const
, at least in the case of wasm32-wasi
.
Merged, thanks.
CLOCK_REALTIME
is not always a literal integer. One counter-example is wasi-libc, where it aliases an internal symbol and therefore is a pointer type. This makes it incompatible with hsc2hs #const, therefore we better use capi import here, which is guaranteed to work uniformly and fixes wasm32-wasi support.