dropped other than dropping its children, then it means `Drop` doesn't need to
be implemented at all!
-**There is no stable way to prevent this behaviour in Rust 1.0.**
+**There is no stable way to prevent this behavior in Rust 1.0.**
Note that taking `&mut self` means that even if you could suppress recursive
Drop, Rust will prevent you from e.g. moving fields out of self. For most types,
happily proceed to tell the box to Drop itself and everything will blow up with
use-after-frees and double-frees.
-Note that the recursive drop behaviour applies to all structs and enums
+Note that the recursive drop behavior applies to all structs and enums
regardless of whether they implement Drop. Therefore something like
```rust
// x goes out of scope; x was uninit; do nothing.
```
-Similarly, branched code where all branches have the same behaviour with respect
+Similarly, branched code where all branches have the same behavior with respect
to initialization has static drop semantics:
```rust
This is pretty clearly Not Good. Unfortunately, we're kind've stuck between a
rock and a hard place: maintaining consistent state at every step has an
enormous cost (and would negate any benefits of the API). Failing to maintain
-consistent state gives us Undefined Behaviour in safe code (making the API
+consistent state gives us Undefined Behavior in safe code (making the API
unsound).
So what can we do? Well, we can pick a trivially consistent state: set the Vec's
len to be 0 when we start the iteration, and fix it up if necessary in the
destructor. That way, if everything executes like normal we get the desired
-behaviour with minimal overhead. But if someone has the *audacity* to
+behavior with minimal overhead. But if someone has the *audacity* to
mem::forget us in the middle of the iteration, all that does is *leak even more*
(and possibly leave the Vec in an unexpected but otherwise consistent state).
Since we've accepted that mem::forget is safe, this is definitely safe. We call
`repr(C)` can be applied to types that will be nonsensical or problematic if
passed through the FFI boundary.
-* ZSTs are still zero-sized, even though this is not a standard behaviour in
-C, and is explicitly contrary to the behaviour of an empty type in C++, which
+* ZSTs are still zero-sized, even though this is not a standard behavior in
+C, and is explicitly contrary to the behavior of an empty type in C++, which
still consumes a byte of space.
* DSTs, tuples, and tagged unions are not a concept in C and as such are never
However if you take a reference to a packed field, it's unlikely that the
compiler will be able to emit code to avoid an unaligned load.
-**[As of Rust 1.0 this can cause undefined behaviour.][ub loads]**
+**[As of Rust 1.0 this can cause undefined behavior.][ub loads]**
`repr(packed)` is not to be used lightly. Unless you have extreme requirements,
this should not be used.
`n`. So alignment 2 means you must be stored at an even address, and 1 means
that you can be stored anywhere. Alignment is at least 1, and always a power of
2. Most primitives are generally aligned to their size, although this is
-platform-specific behaviour. In particular, on x86 `u64` and `f64` may be only
+platform-specific behavior. In particular, on x86 `u64` and `f64` may be only
aligned to 32 bits.
A type's size must always be a multiple of its alignment. This ensures that an
raw allocations, which are exactly the two things that care about
zero-sized types. We need to be careful of two things:
-* The raw allocator API has undefined behaviour if you pass in 0 for an
+* The raw allocator API has undefined behavior if you pass in 0 for an
allocation size.
* raw pointer offsets are no-ops for zero-sized types, which will break our
C-style pointer iterator.
//! This file handles the relationships between free regions --
//! meaning lifetime parameters. Ordinarily, free regions are
-//! unrelated to one another, but they can be related vai implied or
+//! unrelated to one another, but they can be related via implied or
//! explicit bounds. In that case, we track the bounds using the
//! `TransitiveRelation` type and use that to decide when one free
//! region outlives another and so forth.
/// Returns the type `usize`.
fn usize_ty(&mut self) -> Self::Ty;
- /// Returns the literal for `true`
+ /// Returns the literal for `value` as a `usize`.
fn usize_literal(&mut self, value: usize) -> Literal<Self>;
/// Returns the type `bool`.
/// Returns the literal for `true`
fn true_literal(&mut self) -> Literal<Self>;
- /// Returns the literal for `true`
+ /// Returns the literal for `false`
fn false_literal(&mut self) -> Literal<Self>;
/// Returns a reference to `PartialEq::<T,T>::eq`
}
```
-Try using `{}` isntead:
+Try using `{}` instead:
```
fn bar(foo: Foo) -> u32 {
some types will not implement `Clone`, and thus will not get this method.
In our erroneous example, however, we're referencing a single concrete type.
-Since we know for certain that Wrapper<u32> implements Clone, there's no reason
-to also specify it in a `where` clause.
+Since we know for certain that `Wrapper<u32>` implements `Clone`, there's no
+reason to also specify it in a `where` clause.
"##,
E0194: r##"
do_something function. This is not legal: `Foo::Bar` is a value of type `Foo`,
not a distinct static type. Likewise, it's not legal to attempt to
`impl Foo::Bar`: instead, you must `impl Foo` and then pattern match to specify
-behaviour for specific enum variants.
+behavior for specific enum variants.
"##,
E0249: r##"
projects / rust.git / commitdiff