Closed
Conversation
Member
|
For pipe support, I started adding a few basic capabilities for |
Contributor
|
@olsonjeffery This is really amazing. Thanks so much! I think the main things to do here before merging are change the tmp files and fix the signal handling. The remaining design issues can be iterated on. |
the test "touch"es a new file
…ended - change all uses of Path in fn args to &P - FileStream.read assumptions were wrong (libuv file io is non-positional) - the above will mean that we "own" Seek impl info .. should probably push it in UvFileDescriptor.. - needs more tests
bors
added a commit
that referenced
this pull request
Aug 23, 2013
This PR includes the addition of the essential CRUD functionality exposed as a part of the `uv_fs_*` api. There's a lot more to be done, but the essential abstractions are in place and can be easily expanded. A summary: * `rt::io::file::FileStream` is fleshed out and behaves as a *non-positional* file stream (that is, it has a cursor that can be viewed/changed via `tell` and `seek` * The underlying abstraction in `RtioFileStream` exposes pairs of `read(), write()` and `pread(), pwrite()`. The latter two take explicit `offset` params and don't respect the current cursor location in a file afaik. They both use the same underlying libuv impl * Because libuv explicitly does *not* support `seek`/`tell` operations, these are impl'd in `UvFileStream` by using `lseek(2)` on the raw file descriptor. * I did my best to flesh out and adhere to the stubbing that was already present in `rt::io::file` and the tests should back that up. There may be things missing. * All of the work to test `seek`/`tell` is done in `rt::io::file`, even though the actual impl is down in `rt::uv::uvio`. * We have the ability to spin up an `~RtioFileStream` from a raw file descriptor. This would be useful for interacting with stdin and stdout via newrt. * The lowest level abstractions (in `rt::uv::file`) support fully synchronous/blocking interactions with the uv API and there is a CRUD test using it. This may also be useful for blocking printf, if desired (the default would be non-blocking and uses libuv's io threadpool) There are a few polish things I need to do still (the foremost that I know of is undefined behavior when seek'ing beyond the file's boundary). After this lands, I want to move on to mapping more of the `uv_fs_*` API (especially `uv_fs_stat`). Also a few people have mentioned interest in `uv_pipe_t` support. I'm open to suggestions.
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Apr 7, 2022
Allow raw lint descriptions update_lints now understands raw strings in declare_clippy_lint descriptions. Supersedes rust-lang#8655 cc `@Alexendoo` thanks for addressing this so quickly. I build a little bit simpler version of your patch. I don't think it really matters what `Literal` we're trying to tokenize, since we assume later, that it is some sort of `str`. changelog: none
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR includes the addition of the essential CRUD functionality exposed as a part of the
uv_fs_*api. There's a lot more to be done, but the essential abstractions are in place and can be easily expanded.A summary:
rt::io::file::FileStreamis fleshed out and behaves as a non-positional file stream (that is, it has a cursor that can be viewed/changed viatellandseekRtioFileStreamexposes pairs ofread(), write()andpread(), pwrite(). The latter two take explicitoffsetparams and don't respect the current cursor location in a file afaik. They both use the same underlying libuv implseek/telloperations, these are impl'd inUvFileStreamby usinglseek(2)on the raw file descriptor.rt::io::fileand the tests should back that up. There may be things missing.seek/tellis done inrt::io::file, even though the actual impl is down inrt::uv::uvio.~RtioFileStreamfrom a raw file descriptor. This would be useful for interacting with stdin and stdout via newrt.rt::uv::file) support fully synchronous/blocking interactions with the uv API and there is a CRUD test using it. This may also be useful for blocking printf, if desired (the default would be non-blocking and uses libuv's io threadpool)There are a few polish things I need to do still (the foremost that I know of is undefined behavior when seek'ing beyond the file's boundary).
After this lands, I want to move on to mapping more of the
uv_fs_*API (especiallyuv_fs_stat). Also a few people have mentioned interest inuv_pipe_tsupport. I'm open to suggestions.