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:
commit
1659d65e03
2
configure
vendored
2
configure
vendored
@ -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:
|
||||
//
|
||||
|
Loading…
Reference in New Issue
Block a user