-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace nix with rustix #815
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically 👍 . I didn't find anything that made me go "ewww" and I am fine with trying this out.
To answer to your original comment:
The only issue right now is with RawFdContainer. rustix doesn't deal with RawFds, it uses I/O-safe BorrowedFd and OwnedFd types (not the ones used in Rustc 1.63). This means that I have to reimplement RawFdContainer as a newtype around OwnedFd. This is a breaking change, and I would like to avoid it if possible, but as far as I know there isn't a real way around it.
These are actually the fd types from 1.63 if you use that compiler version, I think? Rustix uses io_lifetimes and that auto-detects std support: https://github.com/sunfishcode/io-lifetimes/blob/8aa962eb169deba71b1785076b8f769a41d3d8c8/build.rs#L99-L112
So... this actually starts the conversion away from RawFdContainer
to using OwnedFd
instead. The two conversions (rustix
and io_lifetimes
) should IMHO not be entangled. Doing it the way you are starting now means we can use the re-exports from rustix and do not have to explicitly depend on io_lifetimes
. ;-)
x11rb/src/rust_connection/stream.rs
Outdated
AddressFamily::UNIX, | ||
SocketType::STREAM, | ||
SocketFlags::CLOEXEC, | ||
Protocol::default(), | ||
)?; | ||
|
||
// Wrap it in a RawFdContainer. Its Drop impl makes sure to close the socket if something | ||
// errors out below. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... this comment could be updated. The Drop
impl of RawFdContainer
is no longer relevant for this, since this is already an OwnedFd
, right? (In fact, there is no longer a Drop
impl)
The thing is, though, that we'd have a public dependency on I'd rather wait for a month or so for Debian Bookworm to release with Rust 1.63, and then just use |
Alternatively, we could have a public dependency on I'm not quite sure whether there is much of a difference between the two options: Since |
I took the liberty of pushing a commit fixing most of my review comments and fixing compilation of the My only remaining comment is this one: #815 (comment) Running the
Actually... why does this fail with something
Edit:
Edit: Opened bytecodealliance/rustix#660 |
Thanks for pushing! |
It looks like the maintainer of |
Realized that I forgot to mark this as ready when 1.63 dropped in Debian Stable. Oh well. It's about ready now, just needs some straightening out. |
Did I miss something? This PR does not bump the MSRV to 1.63 and uses |
I was waiting until Debian Stable released with v1.63.0 in order to make sure DS users aren't left behind. |
This adds a dependency on rustix 0.37. rustix bumped its msrv to Rust 1.63 in version 0.38. So, we would be stuck on Rustix 0.37 until our next MSRV bump. Rustix' readme says:
Uhm... we are a lib, we can't really pin this. This makes me feel uneasy since we already had enough msrv-related problems in the past. On the other hand, x11rb's de-facto MSRV policy is "never update, unless a dependency forces us". Perhaps something like "Debian stable" would actually be a better policy. Dunno. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #815 +/- ##
==========================================
+ Coverage 12.73% 12.78% +0.04%
==========================================
Files 189 189
Lines 137972 138331 +359
==========================================
+ Hits 17568 17679 +111
- Misses 120404 120652 +248
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
I've updated to |
Signed-off-by: Uli Schlachter <[email protected]>
Signed-off-by: Uli Schlachter <[email protected]>
I think I've addressed the rest of the review comments.
|
LGTM @psychon We'll wait for your final review before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not too happy about the MSRV bump, but I guess I am being too conservative here, so whatever. Basically 👍 except for some nits.
(Do I get the steak dinner also if I write a program to run into this error on purpose, instead of just stumbling upon it accidentally? ;-) )
@psychon We'll wait for your final review before merging.
Heh, feel free to approve things if you think it is fine. I'm trying not to be a BDFL. ;-)
Rust 1.63 brings I/O safety, aka std::os::unix::io::OwnedFd. This is quite helpful for FD passing since it allows to get rid of our own RawFdContainer, improving interoperability with other things. This change is already done now in preparation for #815. Let's see what this unleashes in terms of new clippy warnings. Signed-off-by: Uli Schlachter <[email protected]>
Turns out the 1.63 resolver can handle the lifetimes in the async extension functions.
- Update documentation to say 1.63 instead of 1.56 - Remove manual FD count check for sendmsg - Don't derive Hash, PartialEq and Eq for the fallback RawFdContainer - Write a better/unified doc comment for RawFdContainer - Talk about OwnedFd instead of RawFdContainer in namespace generation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! And nice solution for de-duplicating the doc comment on the former RawFdContainer
.
Closes #770 by replacing
nix
withrustix
.rustix
has several advantages overnix
, the prime one being that, on Linux, system calls are done without going through thelibc
. This means that, in certain cases, the system calls can be directly inlined into the functioned that call them.The only issue right now is with
RawFdContainer
.rustix
doesn't deal withRawFd
s, it uses I/O-safeBorrowedFd
andOwnedFd
types (not the ones used in Rustc 1.63). This means that I have to reimplementRawFdContainer
as a newtype aroundOwnedFd
. This is a breaking change, and I would like to avoid it if possible, but as far as I know there isn't a real way around it.I'm filing this as a draft for now to discuss if there is a way around this.