bors fffacb34fe auto merge of #10646 : alexcrichton/rust/issue-10645, r=luqmana ... This is a behavioral difference in libuv between different platforms in different situations. It turns out that libuv on windows will immediately allocate a buffer instead of waiting for data to be ready. What this implies is that we must have our custom data set on the handle before we call uv_read_start. I wish I knew of a way to test this, but this relies to being on the windows platform *and* reading from a true TTY handle which only happens when this is actually attached to a terminal. I have manually verified this works. Closes #10645		2013-11-25 05:46:37 -08:00
..
addrinfo.rs	Move std::rt::io to std::io	2013-11-11 20:44:07 -08:00
async.rs	Make the uv bindings resilient to linked failure	2013-11-10 01:37:11 -08:00
file.rs	Remove linked failure from the runtime	2013-11-24 21:21:12 -08:00
idle.rs	Another round of test fixes from previous commits	2013-11-10 01:37:12 -08:00
lib.rs	Move std::rt::io to std::io	2013-11-11 20:44:07 -08:00
macros.rs	Implement native::IoFactory	2013-11-13 18:34:59 -08:00
net.rs	Remove linked failure from the runtime	2013-11-24 21:21:12 -08:00
pipe.rs	Remove linked failure from the runtime	2013-11-24 21:21:12 -08:00
process.rs	Move std::rt::io to std::io	2013-11-11 20:44:07 -08:00
signal.rs	Move std::rt::io to std::io	2013-11-11 20:44:07 -08:00
stream.rs	Set uv's custom data before uv_read_start	2013-11-24 21:47:13 -08:00
timer.rs	Fix usage of libuv for windows	2013-11-10 12:23:57 -08:00
tty.rs	Allow piped stdout/stderr use uv_tty_t	2013-11-18 16:29:41 -08:00
uvio.rs	Remove linked failure from the runtime	2013-11-24 21:21:12 -08:00
uvll.rs	Fix up mingw64 target.	2013-11-22 20:39:58 -05:00