auto merge of #14764 : jbcrail/rust/fix-more-comments, r=alexcrichton

3 files changed, 3 insertions, 3 deletions

diff --git a/src/libnative/io/pipe_win32.rs b/src/libnative/io/pipe_win32.rs
index 45b12aa7007..b097bde2ad8 100644
--- a/src/libnative/io/pipe_win32.rs
+++ b/src/libnative/io/pipe_win32.rs
@@ -50,7 +50,7 @@
 //! it sounded like named pipes just weren't built for this kind of interaction,
 //! and the suggested solution was to use overlapped I/O.
 //!
-//! I don't realy know what overlapped I/O is, but my basic understanding after
+//! I don't really know what overlapped I/O is, but my basic understanding after
 //! reading about it is that you have an external Event which is used to signal
 //! I/O completion, passed around in some OVERLAPPED structures. As to what this
 //! is, I'm not exactly sure.
diff --git a/src/libnative/io/process.rs b/src/libnative/io/process.rs
index 97b227ae1d8..d8486cb9f09 100644
--- a/src/libnative/io/process.rs
+++ b/src/libnative/io/process.rs
@@ -923,7 +923,7 @@ fn waitpid(pid: pid_t, deadline: u64) -> IoResult<rtio::ProcessExit> {
     // Register a new SIGCHLD handler, returning the reading half of the
     // self-pipe plus the old handler registered (return value of sigaction).
     //
-    // Be sure to set up the self-pipe first because as soon as we reigster a
+    // Be sure to set up the self-pipe first because as soon as we register a
     // handler we're going to start receiving signals.
     fn register_sigchld() -> (libc::c_int, c::sigaction) {
         unsafe {
diff --git a/src/libnative/task.rs b/src/libnative/task.rs
index f16c41d4e28..b073c2c7fbf 100644
--- a/src/libnative/task.rs
+++ b/src/libnative/task.rs
@@ -166,7 +166,7 @@ impl rt::Runtime for Ops {
     //
     // On a mildly unrelated note, it should also be pointed out that OS
     // condition variables are susceptible to spurious wakeups, which we need to
-    // be ready for. In order to accomodate for this fact, we have an extra
+    // be ready for. In order to accommodate for this fact, we have an extra
     // `awoken` field which indicates whether we were actually woken up via some
     // invocation of `reawaken`. This flag is only ever accessed inside the
     // lock, so there's no need to make it atomic.