Reword 'stupid' and 'crazy' in docs.

configure

@@ -1568,7 +1568,7 @@ do
     then
         LLVM_BUILD_DIR=${CFG_BUILD_DIR}$t/llvm
         LLVM_INST_DIR=$LLVM_BUILD_DIR
-        # For some crazy reason the MSVC output dir is different than Unix
+        # For some weird reason the MSVC output dir is different than Unix
         if [ ${is_msvc} -ne 0 ]; then
             if [ -n "$CFG_DISABLE_OPTIMIZE_LLVM" ]
             then

src/doc/nomicon/atomics.md

@@ -24,10 +24,10 @@ exactly what we said but, you know, fast. Wouldn't that be great?
 
 # Compiler Reordering
 
-Compilers fundamentally want to be able to do all sorts of crazy transformations
-to reduce data dependencies and eliminate dead code. In particular, they may
-radically change the actual order of events, or make events never occur! If we
-write something like
+Compilers fundamentally want to be able to do all sorts of complicated
+transformations to reduce data dependencies and eliminate dead code. In
+particular, they may radically change the actual order of events, or make events
+never occur! If we write something like
 
 ```rust,ignore
 x = 1;

src/doc/nomicon/meet-safe-and-unsafe.md

@@ -22,7 +22,7 @@ Well, Rust *has* a safe programming language. Let's step back a bit.
 Rust can be thought of as being composed of two programming languages: *Safe
 Rust* and *Unsafe Rust*. Safe Rust is For Reals  Totally Safe. Unsafe Rust,
 unsurprisingly, is *not* For Reals Totally Safe.  In fact, Unsafe Rust lets you
-do some really crazy unsafe things.
+do some really, *really* unsafe things.
 
 Safe Rust is the *true* Rust programming language. If all you do is write Safe
 Rust, you will never have to worry about type-safety or memory-safety. You will

src/doc/nomicon/races.md

@@ -21,11 +21,11 @@ prevent *all* race conditions would be pretty awful to use, if not just
 incorrect.
 
 So it's perfectly "fine" for a Safe Rust program to get deadlocked or do
-something incredibly stupid with incorrect synchronization. Obviously such a
-program isn't very good, but Rust can only hold your hand so far. Still, a
-race condition can't violate memory safety in a Rust program on
-its own. Only in conjunction with some other unsafe code can a race condition
-actually violate memory safety. For instance:
+something nonsensical with incorrect synchronization. Obviously such a program
+isn't very good, but Rust can only hold your hand so far. Still, a race
+condition can't violate memory safety in a Rust program on its own. Only in
+conjunction with some other unsafe code can a race condition actually violate
+memory safety. For instance:
 
 ```rust,no_run
 use std::thread;

src/libstd/sys/windows/thread_local.rs

@@ -207,7 +207,7 @@ unsafe fn unregister_dtor(key: Key) -> bool {
 // loop to basically match Unix semantics. If we don't reach a fixed point
 // after a short while then we just inevitably leak something most likely.
 //
-// # The article mentions crazy stuff about "/INCLUDE"?
+// # The article mentions weird stuff about "/INCLUDE"?
 //
 // It sure does! Specifically we're talking about this quote:
 //