Permalink
Browse files
Reword 'stupid' and 'crazy' in docs.
- Loading branch information...
|
|
@@ -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