* Get FoundationEssentials building
Adding the missing musl imports to get FoundationEssentials building for
the Swift static SDKs again.
Also providing an option to disable building the macros. The macros
aren't necessary for building the library and will not be run as part of
the static SDK. No need to bloat the SDK or build times further. For
Swift 6, the macros should be provided by the toolchain since the
toolchain and SDK are current revlocked due to swiftmodules.
* Get FoundationInternationalization building
Adding the missing Musl imports to get FoundationInternationalization
building for the static SDK.
* [android] fix the LP32 armv7/i686 android build
* Update Sources/FoundationEssentials/Android+Extensions.swift
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* drop the android Lp32 specific operator &
---------
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* 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
* Add `import WASILibc` statements to libc import chains
* Declare wasm32 arch as 32-bit environment
* Switch to _pointerBitWidth for architecture checks
This change switches the architecture checks in Data.swift to use the
_pointerBitWidth instead of the arch() checks for consistency with newer
platforms.
WASI doesn't have `sendfile`, so we need to implement the copy in user
space with `read` and `write`. It's not as efficient as `sendfile`, but
it's the best we can do.
* Guard out user/group related code on WASI
This change guards out the user/group related code on WASI, as WASI does
not have the concept of users or groups.
* Throw explicit unsupported error if trying to set user or group on WASI
Instead of implicitly ignoring user-given values, we should throw
exception to make it clear that those values cannot be set on WASI.
This adjusts the API usage to account for differences on Android. The
biggest source of difference is the nullability, particularly in the
`fts` APIs. Unfortunately, `MMAP_FAILED` is not imported by the clang
importer due to the casting involved so we manually inline the constant
at the single site.
This adds the necessary guards and includes for the Android modules.
While the module does not compile currently due to nullability
differences (and in some cases missing declarations), this at least
brings the module to a point where we can start working on the errors
and differences to create a maintainable codebase for Android.
Adjust the Windows path for copying (or linking) files. This adds the
missing recursion in the copy (the documentation for `CopyFile2` was not
clear that the recursive copy is not performed).
Rather than relaying the underlying system error, replace the error with
the expected error code. This repairs the test case expectation of the
thrown error.
In the case that the destination exists, we should check for continue
after error. If the source does not exist, simply do nothing.
Furthermore, adjust the test to ensure that we are using the path
spelling rather than the FSR.
Take the opportunity to correct an error in the tests where we would not
check the correct captured item set.
When running the test suite we would hit an infinite loop due to the use
of the relative path rather than the absolute path for accessing the
attributes of the file entry.
The condition of the error check was inverted as it was meant to be a
`guard` statement. This was resulting in an infinite loop. With this we
now pass a few additional tests and the test suite no longer hangs.
This adds an initial implementation for file operations on Windows. With
this, `FileManager` should at least build on Windows, which unblocks
future work as well as brings us closer to enabling
`FoundationEssentials` on Windows.
This allows us to get further into building FoundationEssentials once
again on Windows. Much of the file system work has resulted in this
module no longer being viable on Windows and will need to be replaced to
allow building on Windows which does not have the `fts` APIs.
* (123438249) FileManager.removeItem does not throw error when encoutering long paths
The change makes swift-foundation FileManager.removeItem properly throw
on removefile(3) errors.
* Conform POSIXError to Error
* Clean up warnings and produce more detailed test failures
* Fix macOS CI failure
