std::rt improvements

[alexcrichton]

Large topics:

• Implemented rt::io::net::unix. We've got an implementation backed by "named pipes" for windows for free from libuv, so I'm not sure if these should be cfg(unix) or whether they'd be better placed in rt::io::pipe (which is currently kinda useless), or to leave in unix. Regardless, we probably shouldn't deny windows of functionality which it certainly has.
• Fully implemented net::addrinfo, or at least fully implemented in the sense of making the best attempt to wrap libuv's getaddrinfo api
• Moved standard I/O to a libuv TTY instead of just a plain old file descriptor. I found that this interacted better when closing stdin, and it has the added bonus of getting things like terminal dimentions (someone should make a progress bar now!)
• Migrate to ~Trait instead of a typedef'd object where possible. There are only two more types which are blocked on this, and those are traits which have a method which takes by-value self (there's an open issue on this)
• Drop rt::io::support::PathLike in favor of just ToCStr. We recently had a lot of Path work done, but it still wasn't getting passed down to libuv (there was an intermediate string conversion), and this allows true paths to work all the way down to libuv (and anything else that can become a C string).
• Removes extra::fileinput and extra::io_util

Closes #9895
Closes #9975
Closes #8330
Closes #6850 (ported lots of libraries away from std::io)
cc #4248 (implemented unix/dns)
cc #9128 (made everything truly trait objects)

[alexcrichton]

I tried to keep each commit separate from the others, so this may be best inspected commit-by-commit. I tried to keep this small but things kinda just snowballed into one another.

[thestinger]

By standard I/O do you mean stdout and stdin? Does it still work properly when the program isn't running in a terminal, and output is piped somewhere else?

[alexcrichton]

Ah yes, I do mean stdout/stdin. And yes, turns out libuv is pretty smart and handles them fine if they're redirected as well as attached to a terminal.

[alexcrichton]

This is still a little in-flux as it's not passing make check. Most of the trouble seems to come down to blocking vs non-blocking stdio. When we use the TTY handles from libuv, it sets the file descriptors in non-blocking mode, but then when we making blocking calls with io::native it returns an error EAGAIN. This is pretty normal, but right now there's no condition handler registered which ends up in all sorts of disaster.

There are only 2 users of native::stdio which are logging and dumb_println. I'm moving logging to uv stdio (or whatever the local event loop provides), and then I'm modifying dumb_println to handle EAGAIN, although this shouldn't be called that often (only rterrln! and rtabort! use it currently, and maybe rtdebug!).

I've also finished migrating everything to a trait object instead of using typedefs.

I'll update this once I have everything passing make check

[alexcrichton]

Notable new changes

• extra::fileinput was removed
• extra::io_util was removed
• task failure logging now forcibly goes to the console instead of going through the task logger (see comments in the commit/file)

[bill-myers]

@alexcrichton if libuv indeed sets stdin/stdout to non-blocking, won't that also wreak havoc with C libraries doing printf, etc.? It seems doing such a thing is fundamentally wrong, and libuv should either learn to do async I/O without setting things to non-blocking (i.e. poll before read/write) or use a separate thread for stdin/stdout with blocking calls

[alexcrichton]

I've explicitly chosen to make stdout/stderr as async instead of synchronous, but we can tell libuv to make synchronous writes instead. We're forced to make stdin async, however, but I think that it's less of a problem.

That is an interesting concern though. I doubt any c library would panic or anything (who checks the return value of printf?), but it would mean that some prints could possibly get lost. This doesn't happen 100% of the time (only when another write is currently in-flight I believe), so it's not like it would invalidate all FFI printfs, but it probably wouldn't be great either.

[brson]

Heroic effort! 🌊