De-wrap warning blocks

Author: ehuss

src/behavior-considered-undefined.md

@@ -14,13 +14,7 @@ undefined behavior, it is *unsound*.
 
 <div class="warning">
 
-***Warning:*** The following list is not exhaustive; it may grow or shrink.
-There is no formal model of Rust's semantics for what is and is not allowed in
-unsafe code, so there may be more behavior considered unsafe. We also reserve
-the right to make some of the behavior in that list defined in the future. In
-other words, this list does not say that anything will *definitely* always be
-undefined in all future Rust version (but we might make such commitments for
-some list items in the future).
+***Warning:*** The following list is not exhaustive; it may grow or shrink. There is no formal model of Rust's semantics for what is and is not allowed in unsafe code, so there may be more behavior considered unsafe. We also reserve the right to make some of the behavior in that list defined in the future. In other words, this list does not say that anything will *definitely* always be undefined in all future Rust version (but we might make such commitments for some list items in the future).
 
 Please read the [Rustonomicon] before writing unsafe code.
 

src/items/external-blocks.md

@@ -294,10 +294,7 @@ that symbol rather than having to look it up by name.
 
 <div class="warning">
 
-Warning: `link_ordinal` should only be used in cases where the ordinal of the
-symbol is known to be stable: if the ordinal of a symbol is not explicitly set
-when its containing binary is built then one will be automatically assigned to
-it, and that assigned ordinal may change between builds of the binary.
+Warning: `link_ordinal` should only be used in cases where the ordinal of the symbol is known to be stable: if the ordinal of a symbol is not explicitly set when its containing binary is built then one will be automatically assigned to it, and that assigned ordinal may change between builds of the binary.
 
 </div>
 

src/names/preludes.md

@@ -93,9 +93,7 @@ The *`no_std` [attribute]* may be applied at the crate level to prevent the
 
 <div class="warning">
 
-Warning: Using `no_std` does not prevent the standard library from being
-linked in. It is still valid to put `extern crate std;` into the crate and
-dependencies can also link it in.
+Warning: Using `no_std` does not prevent the standard library from being linked in. It is still valid to put `extern crate std;` into the crate and dependencies can also link it in.
 
 </div>
 

src/patterns.md

@@ -144,9 +144,7 @@ Since negative numbers are not [literals], literal patterns also accept an optio
 
 <div class="warning">
 
-C string and raw C string literals are accepted in literal patterns, but `&CStr`
-doesn't implement structural equality (`#[derive(Eq, PartialEq)]`) and therefore
-any such `match` on a `&CStr` will be rejected with a type error.
+C string and raw C string literals are accepted in literal patterns, but `&CStr` doesn't implement structural equality (`#[derive(Eq, PartialEq)]`) and therefore any such `match` on a `&CStr` will be rejected with a type error.
 
 </div>
 

src/type-layout.md

@@ -256,9 +256,7 @@ struct.size = current_offset + padding_needed_for(current_offset, struct.alignme
 
 <div class="warning">
 
-Warning: This pseudocode uses a naive algorithm that ignores overflow issues for
-the sake of clarity. To perform memory layout computations in actual code, use
-[`Layout`].
+Warning: This pseudocode uses a naive algorithm that ignores overflow issues for the sake of clarity. To perform memory layout computations in actual code, use [`Layout`].
 
 </div>
 
@@ -310,13 +308,7 @@ the default `enum` size and alignment for the target platform's C ABI.
 
 <div class="warning">
 
-Warning: There are crucial differences between an `enum` in the C language and
-Rust's [field-less enums] with this representation. An `enum` in C is
-mostly a `typedef` plus some named constants; in other words, an object of an
-`enum` type can hold any integer value. For example, this is often used for
-bitflags in `C`. In contrast, Rust’s [field-less enums] can only legally hold
-the discriminant values, everything else is [undefined behavior]. Therefore,
-using a field-less enum in FFI to model a C `enum` is often wrong.
+Warning: There are crucial differences between an `enum` in the C language and Rust's [field-less enums] with this representation. An `enum` in C is mostly a `typedef` plus some named constants; in other words, an object of an `enum` type can hold any integer value. For example, this is often used for bitflags in `C`. In contrast, Rust’s [field-less enums] can only legally hold the discriminant values, everything else is [undefined behavior]. Therefore, using a field-less enum in FFI to model a C `enum` is often wrong.
 
 </div>