Auto merge of #38782 - clarcharr:stupid, r=GuillaumeGomez

Reword 'stupid' and 'crazy' in docs.

These terms are not very descriptive and are better reworded as something else.
This commit is contained in:
bors 2017-01-03 02:21:00 +00:00
commit 1659d65e03
5 changed files with 12 additions and 12 deletions

2
configure vendored
View File

@ -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

View File

@ -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;

View File

@ -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

View File

@ -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;

View File

@ -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:
//