* wasi-common: need FileEntry to track the mode with which a file was opened
* add a test for read, write access modes in path_open
* a directory needs to report full set of rights in fdstat
implementations such as wasi-libc use these as a mask for any rights
they request for a new fd when invoking path_open
* preview2: mask file perms. and we really need to enforce them on stream creation
which will mean editing the wit.
* filesystem.wit: make {read, write, append}-via-stream fallible with an error-code
in order to fail appropriately when a file is not open for reading or
writing.
* filesystem.wit: update comments
* preview2 impls: fix error handling for {read,write,append}_via_stream
* wasi-common: normalize wrong access mode error on windows to badf
* remove kubkob from labeler
I appreciate his work on this stuff in the past but he hasnt been around
for a few years now
* preview 2 filesystem: allow stat on any opened fd
since file perms is now more accurately the file's access mode, a file
open for writing was having problems here.
in reality i dont think it makes sense to restrict this based on the
perms. if a file is opened, you should be able to stat it.
this fixes the host adapter's path_link test, which was broken by prior
changes. additionally, this fix lets the path_open_dirfd_not_dir test
pass.
* fix the directory base & inheriting rights
in order to work with wasi-testsuite, it needs to be possible to
path_open(dirfd, ".", ...) with the same rights reported in the
fdstat of that dirfd. When we report the Rights::all() set, both
FD_READ and FD_WRITE are set in the base rights, which results in
unix rejecting an openat2(dirfd, ".", O_RDWR) with EISDIR.
By not having the FD_READ and FD_WRITE rights present in the base
rights, the open syscall defaults to O_RDONLY, which is the only
access mode allowed for opening directories.
* path_open of a directory with read and write succeeds on windows
Peepmatic was an early attempt at a DSL for peephole optimizations, with the
idea that maybe sometime in the future we could user it for instruction
selection as well. It didn't really pan out, however:
* Peepmatic wasn't quite flexible enough, and adding new operators or snippets
of code implemented externally in Rust was a bit of a pain.
* The performance was never competitive with the hand-written peephole
optimizers. It was *very* size efficient, but that came at the cost of
run-time efficiency. Everything was table-based and interpreted, rather than
generating any Rust code.
Ultimately, because of these reasons, we never turned Peepmatic on by default.
These days, we just landed the ISLE domain-specific language, and it is better
suited than Peepmatic for all the things that Peepmatic was originally designed
to do. It is more flexible and easy to integrate with external Rust code. It is
has better time efficiency, meeting or even beating hand-written code. I think a
small part of the reason why ISLE excels in these things is because its design
was informed by Peepmatic's failures. I still plan on continuing Peepmatic's
mission to make Cranelift's peephole optimizer passes generated from DSL rewrite
rules, but using ISLE instead of Peepmatic.
Thank you Peepmatic, rest in peace!