-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Allow redirecting subprocess stdout to our stderr etc. (redux) #114590
Conversation
This involves adding a new variant `imp::Stdio::StaticFd`. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
We're going to want to reuse this bit of code.
This involves a new variant `imp;::Stdio::InheritSpecific`. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
(rustbot has picked a reviewer for you, use r? to override) |
I can understand splitting the refactor out from the rest, but I would recommend squashing the first, third, and fourth commits together since they each touch a different file and are tightly linked. |
#88561 as initially submitted had the same commit structure and the maintainers didn't seem to object to it then, and I prefer it this way so I will leave this as it is unless the reviewer would like me to squash it. (When I'm a reviewer, I generally prefer the commits as small as possible. It's always possible to review successive commits together if the submitter has split them up; whereas if the submitter has merged them, I can only review them in that form or ask for a resubmission.) |
I don't think that really means anything. I don't think they care about commit structure at all until the very end, where they might ask for everything to be squashed.
The way I see it commits 1, 3, and 4 are all part of the same change. Neither 1 nor 3 make sense without 4, so they should be combined. I would never have committed them separately in the first place. But that's just my suggestion. Keep it how you like it. |
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.
Thank you! This is terrific.
T-libs-api FCP has completed in #88561 (comment).
Thank you for sticking with this over 2 years 😮👏 while our team has been so backlogged -- we're starting to make better progress again recently.
@bors r+ |
Allow redirecting subprocess stdout to our stderr etc. (redux) This is the code from rust-lang#88561, tidied up, including review suggestions, and with the for-testing-only CI commit removed. FCP for the API completed in rust-lang#88561. I have made a new MR to facilitate review. The discussion there is very cluttered and the branch is full of changes (in many cases as a result of changes to other Rust stdlib APIs since then). Assuming this MR is approvedl we should close that one. ### Reviewer doing a de novo review Just code review these four commits.. FCP discussion starts here: rust-lang#88561 (comment) Portability tests: you can see that this branch works on Windows too by looking at the CI results in rust-lang#88561, which has the same code changes as this branch but with an additional "DO NOT MERGE" commit to make the Windows tests run. ### Reviewer doing an incremental review from some version of rust-lang#88561 Review the new commits since your last review. I haven't force pushed the branch there. git diff the two branches (eg `git diff 176886197d6..0842b69c219`). You'll see that the only difference is in gitlab CI files. You can also see that *this* MR doesn't touch those files.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@rustbot author |
…Stdio This implementation is wrong. Like the impl for From<File>, it is forced to panic because process::Stdio in unsupported/process.rs doesn't have a suitable variant. The root cause of the problem is that process::Stdio in unsupported/process.rs has any information in it at all. I'm pretty sure that it should just be a unit struct. However, making that build on all platforms is going to be a lot of work, iterating through CI and/or wrestling Docker. I don't think this extra panic is making things significantly worse. For now I have added some TODOs.
This comment has been minimized.
This comment has been minimized.
Thanks for the review and the encouragement. I've fixed WASM (with some flail). Please LMK when you want me to squash this. Hopefully it will turn out not to break some other platform too. @rustbot reviewer |
3124903
to
436fe01
Compare
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (559421e): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 629.671s -> 628.555s (-0.18%) |
This is the code from #88561, tidied up, including review suggestions, and with the for-testing-only CI commit removed. FCP for the API completed in #88561.
I have made a new MR to facilitate review. The discussion there is very cluttered and the branch is full of changes (in many cases as a result of changes to other Rust stdlib APIs since then). Assuming this MR is approvedl we should close that one.
Reviewer doing a de novo review
Just code review these four commits.. FCP discussion starts here: #88561 (comment)
Portability tests: you can see that this branch works on Windows too by looking at the CI results in #88561, which has the same code changes as this branch but with an additional "DO NOT MERGE" commit to make the Windows tests run.
Reviewer doing an incremental review from some version of #88561
Review the new commits since your last review. I haven't force pushed the branch there.
git diff the two branches (eg
git diff 176886197d6..0842b69c219
). You'll see that the only difference is in gitlab CI files. You can also see that this MR doesn't touch those files.