auto merge of #16982 : jbcrail/rust/comment-and-string-corrections, r=alexcrichton

I corrected spelling and capitalization errors in comments and strings.

5 files changed, 8 insertions, 8 deletions

diff --git a/src/libnative/io/net.rs b/src/libnative/io/net.rs
index 368b5914444..cbfc673e6af 100644
--- a/src/libnative/io/net.rs
+++ b/src/libnative/io/net.rs
@@ -901,8 +901,8 @@ impl rtio::RtioUdpSocket for UdpSocket {
 //
 // It turns out that there's this nifty MSG_DONTWAIT flag which can be passed to
 // send/recv, but the niftiness wears off once you realize it only works well on
-// linux [1] [2]. This means that it's pretty easy to get a nonblocking
-// operation on linux (no flag fiddling, no affecting other objects), but not on
+// Linux [1] [2]. This means that it's pretty easy to get a nonblocking
+// operation on Linux (no flag fiddling, no affecting other objects), but not on
 // other platforms.
 //
 // To work around this constraint on other platforms, we end up using the
@@ -922,7 +922,7 @@ impl rtio::RtioUdpSocket for UdpSocket {
 // operations performed in the lock are *nonblocking* to avoid holding the mutex
 // forever.
 //
-// So, in summary, linux uses MSG_DONTWAIT and doesn't need mutexes, everyone
+// So, in summary, Linux uses MSG_DONTWAIT and doesn't need mutexes, everyone
 // else uses O_NONBLOCK and mutexes with some trickery to make sure blocking
 // reads/writes are still blocking.
 //
diff --git a/src/libnative/io/pipe_windows.rs b/src/libnative/io/pipe_windows.rs
index 95afa11f4a9..1f1880d712d 100644
--- a/src/libnative/io/pipe_windows.rs
+++ b/src/libnative/io/pipe_windows.rs
@@ -655,7 +655,7 @@ impl UnixAcceptor {
         // using the original server pipe.
         let handle = self.listener.handle;
 
-        // If we've had an artifical call to close_accept, be sure to never
+        // If we've had an artificial call to close_accept, be sure to never
         // proceed in accepting new clients in the future
         if self.inner.closed.load(atomic::SeqCst) { return Err(util::eof()) }
 
diff --git a/src/libnative/io/process.rs b/src/libnative/io/process.rs
index 0cc7158bb5d..cad2ed0b97e 100644
--- a/src/libnative/io/process.rs
+++ b/src/libnative/io/process.rs
@@ -151,7 +151,7 @@ impl rtio::RtioProcess for Process {
         #[cfg(unix)] use libc::EINVAL as ERROR;
         #[cfg(windows)] use libc::ERROR_NOTHING_TO_TERMINATE as ERROR;
 
-        // On linux (and possibly other unices), a process that has exited will
+        // On Linux (and possibly other unices), a process that has exited will
         // continue to accept signals because it is "defunct". The delivery of
         // signals will only fail once the child has been reaped. For this
         // reason, if the process hasn't exited yet, then we attempt to collect
diff --git a/src/libnative/io/timer_unix.rs b/src/libnative/io/timer_unix.rs
index 06b78a54e53..801434f8101 100644
--- a/src/libnative/io/timer_unix.rs
+++ b/src/libnative/io/timer_unix.rs
@@ -8,12 +8,12 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-//! Timers for non-linux/non-windows OSes
+//! Timers for non-Linux/non-Windows OSes
 //!
 //! This module implements timers with a worker thread, select(), and a lot of
 //! witchcraft that turns out to be horribly inaccurate timers. The unfortunate
 //! part is that I'm at a loss of what else to do one these OSes. This is also
-//! why linux has a specialized timerfd implementation and windows has its own
+//! why Linux has a specialized timerfd implementation and windows has its own
 //! implementation (they're more accurate than this one).
 //!
 //! The basic idea is that there is a worker thread that's communicated to via a
diff --git a/src/libnative/io/tty_windows.rs b/src/libnative/io/tty_windows.rs
index e98fe1e20b1..7f344279cd5 100644
--- a/src/libnative/io/tty_windows.rs
+++ b/src/libnative/io/tty_windows.rs
@@ -15,7 +15,7 @@
 //! This module contains the implementation of a Windows specific console TTY.
 //! Also converts between UTF-16 and UTF-8. Windows has very poor support for
 //! UTF-8 and some functions will fail. In particular ReadFile and ReadConsole
-//! will fail when the codepage is set to UTF-8 and a unicode character is
+//! will fail when the codepage is set to UTF-8 and a Unicode character is
 //! entered.
 //!
 //! FIXME