* Advise porter on where to make necessary change.
In #1075 the change was already made for BSD (thank you!); my working
edit had this guidance to ensure future porters get an error directing
them where to make a necessary change.
Otherwise, the FoundationEssentials build will fail and complain these
variables are not defined but not have guidance as to where they are
sourced from.
* OpenBSD does not support extended attributes.
* OpenBSD does not have secure_getenv.
* Remaining OpenBSD changes.
* OpenBSD also needs `pthread_mutex_t?`.
* Originally I followed Darwin's check with `d_namlen`, but this should
work too.
* Correct statvfs type casts for OpenBSD.
On OpenBSD, fsblkcnt_t -- the type of f_blocks -- is a UInt64; therefore,
so must `blockSize` be.
Ultimately, both sides of the `totalSizeBytes` multiplication should
probably be type cast for all platforms, but that's a more significant
functional change for another time.
* Default activeProcessorCount to 1, not 0.
After a rather tedious debugging session trying to figure out why
swiftpm-bootstrap appeared to be deadlocked, this turned out to be the
culprit. Perhaps this should be #error instead, but for now, set a
sensible default.
* Use sysconf for activeProcessorCount.
This is what Dispatch does in some places for OpenBSD anyway, so do
likewise here.
05975959e67f57063445baabb652262dd764cc72 added a use of `O_NONBLOCK` but
the constant cannot be imported from wasi-libc through ClangImporter
directly, so we need to add a shim for it as well as other constants.
* FreeBSD platform specific fixes
- Use "/usr/share/zoneinfo"
- Use platform specific types and values
- Implement extattr ops for FreeBSD
- Use copy_file_range(2) for file cloning
* Revise patch to ProcessInfo to reduce potential impact to other platforms
* Fix macOS build
* typo
* take suggested change
* Gate `fchown` and `fchmod` calls behind `os(WASI)`
They are not available on WASI, so we gate them behind `os(WASI)`.
* Add missing constant shims for wasi-libc
* Use `futimens` instead of legacy `futimes`
wasi-libc does not provide `futimes` as it is a legacy function.
574b88da48/libc-top-half/musl/include/sys/time.h (L34)
It seems like we don't use neither setjmp nor longjmp in the Foundation
codebase, so we can safely remove this include.
The main motivation for this change is to fix the build with the latest
wasi-libc version. Recent wasi-libc versions started to provide
`setjmp.h` header but it raises compilation errors unless Exception
Handling feature (still under standardization process) is enabled.
See https://github.com/WebAssembly/wasi-libc/blob/wasi-sdk-22/libc-top-half/musl/include/setjmp.h
* Port directory enumeration related code to WASI
For now wasi-libc does not include fts(3) implementation, so mark
features depending on it as unsupported on WASI. Once wasi-libc includes
fts or we decide to implement and maintain our own fts-like API, we can
remove these `#if os(WASI)` guards.
wasi-libc issue tracking fts support:
https://github.com/WebAssembly/wasi-libc/issues/520
Also, wasi-libc defines some constants in a way that ClangImporter can't
understand, so we need to grab them manually through _FoundationCShims in
function call form.
* Delegate error throwing decisions to the delegate
* [windows] do not import stdatomic on windows as it doesn't work with c++ interop enabled
Works around https://github.com/swiftlang/swift/issues/75720
* remove the stdatomic include alltogether
* Enable wasi-libc emulation features
Those features require explicit macro definitions to be enabled, so add
them to the package definition. Only affects WASI builds.
* Prefer `TARGET_OS_WASI` over `__wasi__`
And explain why we need definition checks for `signal.h` and `sys/mman.h`
C functions with `()` as parameter list can take any number of
parameters. But WebAssembly requires static signature information for
every function call, so we need to explicitly specify `(void)` to
indicate that the function takes no parameters.
