Permalink
Browse files

Reword 'stupid' and 'crazy' in docs.

  • Loading branch information...
1 parent df61658 commit 8ffc3e779020808e2437389e0aa559d9b028b061 @clarcharr clarcharr committed Jan 2, 2017
View
@@ -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
@@ -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;
@@ -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
@@ -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;
@@ -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:
//

0 comments on commit 8ffc3e7

Please sign in to comment.