Pointers needed on WASILibc

[yonihemi]

(no pun intended)

Hi!
I'm trying to get ZipFoundation to work in SwiftWasm.
Already got zlib building so we're getting there.

Now, when Swift code calls types like FILE or values like SEEK_SET which are missing, I'm assuming those can be included by tweaking https://github.com/swiftwasm/swift/blob/swiftwasm/stdlib/public/Platform/wasi.modulemap.gyb, correct?

(For example, perhaps these should do the trick:

#undef __DEFINED_FILE
#define __NEED_struct__IO_FILE
#define __need_FILE

).
On that note, I'm trying to track down the exact source of /usr/share/wasi-sysroot/share/wasm32-wasi/predefined-macros.txt included in the toolchain, (which includes #define __DEFINED_FILE, which we probably don't want) and how/if it affects the build.

[MaxDesiatov]

Did you have a look at wasi-libc source code? https://github.com/WebAssembly/wasi-libc/blob/378fd4b21aab6d390f3a1c1817d53c422ad00a62/libc-top-half/musl/include/stdio.h#L14

Usually it's just easier to #if !os(WASI) pieces with file IO in library code than to make it work on the lower level. It also won't require you to rebuild the toolchain after you make these adjustments. Besides, I hope that in the future we'll be able to provide slim builds option that avoids WASI completely. The WASI polyfill that bridges these low-level APIs to JavaScript is about ~300kb, not even taking WASI libc itself into account.

OTOH, if a library relies on Foundation, then yes, tweaking WASI libc may be more appropriate, I'm not sure if we'll ever make Foundation work without WASI...

[yonihemi]

Thanks! I am focusing on some Foundation or lower things ATM so seems like have no choice.

[MaxDesiatov]

I think predefined-macros.txt is automatically generated from wasi-libc source code, but I may be wrong. @kateinoigakukun worked on setting the WASILibc module up, so maybe he could provide some pointers 😄

[kateinoigakukun]

I faced similar problems when developing chibi-link

Now FILE is not defined in wasi-libc and ClangImporter can't import incomplete named type, so FILE is not imported and FILE * is translated as OpaquePointer.

If wasi-libc provides complete FILE structure, FILE type will be imported in Swift. But wasi-libc doesn't use FILE as static sized type, so I think wasi-libc team makes FILE as incomplete type intentionally.

ref: https://github.com/WebAssembly/wasi-libc/blob/378fd4b21aab6d390f3a1c1817d53c422ad00a62/libc-top-half/musl/src/stdio/__fdopen.c#L27

And SEEK_SET can't be imported because it's defined as a function like macro. ClangImporter can't import function like macros

I think we can re-define those constants in WASI.swift.gyb