Upstream libuv patches and upgrade libuv #6567
Comments
|
I saw that you already updated the submodule. I took the current patches and rebased in a single commit on top of libuv HEAD, it is at lucab/libuv@f71151f. If @ILyoan is fine with it, I'd like to send a PR upstream for this. |
|
I don't mind if it works on android smoothly. |
|
why not. feel free to send a PR |
|
In the meanwhile I spotted an almost identical PR to libuv for android: joyent/libuv#805 |
|
Ok, the other PR has just been merged. |
|
Unfortunately, it looks like I won't be able to upgrade libuv at this time. The main blocker for me was that I just couldn't get libuv master to build on mingw right now. If that can be done, I think that we can revisit upgrading libuv. @olsonjeffery mentions that the libuv folks aren't really supporting mingw as a first class platform, they prefer msvc. |
…r=brson This overhauls `std::run` to instead run on top of libuv. This is *not* in a mergeable state, I've been attempting to diagnose failures in the compiletest suite. I've managed to find a fair number of bugs so far, but I still don't seem to be done yet. Notable changes: * This requires upgrading libuv. From the discussion on #6567, I took libuv master from a few days ago, applied one patch to fix process spawning with multiple event loops in libuv, and pushed to my own fork * The build system for libuv has changed since we last used it. There's some extra checkout from a google build system which apparently does all the magic if you don't want to require autotools, and the google system just requires python. I updated the Makefile to get this build system and build libuv with it instead. This is untested on windows and arm, and both will probably need to see some improvement. * This required adding some pipe bindings to libuv as well. Currently the support is pretty simple and probably completely unsafe for pipes, but you at least get read/write methods. This is necessary for capturing output of processes. * I didn't redesign `std::run` at all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses of `std::run` in the compiler still work just fine. I'm not quite sure how the rest of the runtime deals with this, but I marked process structures as `no_send` because the waiting/waking up has to happen in the same event loop right now. If processes start migrating between event loops then very bad things can happen. This may be what threadsafe I/O would fix, and I would be more than willing to rebase on that if it lands first. Anyway, for now I wanted to put this up for review, I'm still investigating the corruption/deadlock bugs, but this is in an *almost* workable state. Once I find the bugs I'll also rebase on the current master.
…arth Fix path_to_res for enum inherent items changelog: none I tried to add `Option::is_some` to the paths but got a false positive from the invalid paths lint. Turns out the `path_to_res` function does not find inherent impls for enums. I fixed this and took the liberty to do some additional cleanup in the method.
`manual_filter_map` and `manual_find_map` changelog: Add `manual_filter_map` and replace `find_map` with `manual_find_map` Replaces rust-lang#6453 Fixes rust-lang#3188 Fixes rust-lang#4193 ~Depends on rust-lang#6567 (to fix an internal lint false positive)~ This replaces `filter_map` and `find_map` with `manual_filter_map` and `manual_find_map` respectively. However, `filter_map` is left in place since it is used for a variety of other cases. See discussion in rust-lang#6453.
We have several android patches and two patches cherry-picked from upstream libuv.
The text was updated successfully, but these errors were encountered: