about summary refs log tree commit diff
path: root/src/libstd/sys/wasi/ext/fs.rs
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-538/+0
2020-07-07Make WASI's FileExt's read_at/write_at consistent with other targets.Dan Gohman-4/+43
Rename the existing read_at/write_at to read_vectored_at/write_vectored_at, for consistency with libstd's read_vectored/write_vectored. And, introduce new read_at/write_at functions which take a single buffer, similar to all other targets which provide these functions, so this will make it easier for applications to share code between WASI and other targets. Note that WASI's FileExt is currently unstable.
2020-07-07Add `read_exact_at` and `write_all_at` to WASI's `FileExt`Dan Gohman-0/+94
This adds `read_exact_at` and `write_all_at` to WASI's `FileExt`, similar to the Unix versions of the same names.
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-1/+1
2019-12-03Update the `wasi` crate for `wasm32-wasi`Alex Crichton-63/+54
This commit updates the `wasi` crate used by the standard library which is used to implement most of the functionality of libstd on the `wasm32-wasi` target. This update comes with a brand new crate structure in the `wasi` crate which caused quite a few changes for the wasi target here, but it also comes with a significant change to where the functionality is coming from. The WASI specification is organized into "snapshots" and a new snapshot happened recently, so the WASI APIs themselves have changed since the previous revision. This had only minor impact on the public facing surface area of libstd, only changing on `u32` to a `u64` in an unstable API. The actual source for all of these types and such, however, is now coming from the `wasi_preview_snapshot1` module instead of the `wasi_unstable` module like before. This means that any implementors generating binaries will need to ensure that their embedding environment handles the `wasi_preview_snapshot1` module.
2019-08-21fixesnewpavlov-0/+2
2019-08-19use wasi cratenewpavlov-4/+4
2019-04-27Stabilized vectored IOSteven Fackler-5/+5
This renames `std::io::IoVec` to `std::io::IoSlice` and `std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes `std::io::IoSlice`, `std::io::IoSliceMut`, `std::io::Read::read_vectored`, and `std::io::Write::write_vectored`. Closes #58452
2019-04-03wasi: Fill out `std::fs` module for WASIAlex Crichton-0/+412
This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented, such as permissions-related ones and `canonicalize`, but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd`, a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI, namely `*at` syscalls (opening a file relative to an already opened one, for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path, but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about "pre opened" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors, and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use, so we implement it for now and will swap it out as soon as one is available.