Merge pull request #11 from simonsan/fixes

Fixes for mdbook test

Author: KodrAus

src/code-considerations/breaking-changes/fundamental.md

@@ -17,7 +17,7 @@ Typically, the scope of [breakage in new trait impls](./reviewing-code/breakage/
 
 Look out for blanket trait implementations for fundamental types, like:
 
-```rust
+```rust,ignore
 impl<'a, T> PublicTrait for &'a T
 where
     T: SomeBound,

src/code-considerations/breaking-changes/new-trait-impls.md

@@ -8,12 +8,12 @@ Also see [`#[fundamental]` types](./fundamental.md) for special considerations f
 
 Rust will use the fact that there's only a single impl for a generic trait during inference. This breaks once a second impl makes the type of that generic ambiguous. Say we have:
 
-```rust
+```rust,ignore
 // in `std`
 impl From<&str> for Arc<str> { .. }
 ```
 
-```rust
+```rust,ignore
 // in an external `lib`
 let b = Arc::from("a");
 ```
@@ -27,7 +27,7 @@ impl From<&str> for Arc<str> { .. }
 
 then
 
-```rust
+```rust,ignore
 let b = Arc::from("a");
 ```
 
@@ -39,14 +39,14 @@ This kind of breakage can be ok, but a [crater] run should estimate the scope.
 
 Rust will use deref coercion to find a valid trait impl if the arguments don't type check directly. This only seems to occur if there's a single impl so introducing a new one may break consumers relying on deref coercion. Say we have:
 
-```rust
+```rust,ignore
 // in `std`
 impl Add<&str> for String { .. }
 
 impl Deref for String { type Target = str; .. }
 ```
 
-```rust
+```rust,ignore
 // in an external `lib`
 let a = String::from("a");
 let b = String::from("b");
@@ -56,14 +56,14 @@ let c = a + &b;
 
 then we add:
 
-```diff
+```diff,ignore
 impl Add<&str> for String { .. }
 + impl Add<char> for String { .. }
 ```
 
 then
 
-```rust
+```rust,ignore
 let c = a + &b;
 ```
 

src/code-considerations/safety-and-soundness/generics-and-unsafe.md

@@ -4,7 +4,7 @@ Be careful of generic types that interact with unsafe code. Unless the generic t
 
 A place where this commonly comes up is with the `RangeBounds` trait. You might assume that the start and end bounds given by a `RangeBounds` implementation will remain the same since it works through shared references. That's not necessarily the case though, an adversarial implementation may change the bounds between calls:
 
-```rust
+```rust,ignore
 struct EvilRange(Cell<bool>);
 
 impl RangeBounds<usize> for EvilRange {

src/code-considerations/safety-and-soundness/may-dangle.md

@@ -6,7 +6,7 @@ If a generic `Type<T>` has a manual drop implementation that may also involve dr
 
 As a real-world example of where this can go wrong, consider an `OptionCell<T>` that looks something like this:
 
-```rust
+```rust,ignore
 struct OptionCell<T> {
     is_init: bool,
     value: MaybeUninit<T>,
@@ -25,7 +25,7 @@ impl<T> Drop for OptionCell<T> {
 
 Adding a `#[may_dangle]` attribute to this `OptionCell<T>` that didn't have a `PhantomData<T>` marker field opened up [a soundness hole](https://github.com/rust-lang/rust/issues/76367) for `T`'s that didn't strictly outlive the `OptionCell<T>`, and so could be accessed after being dropped in their own `Drop` implementations. The correct application of `#[may_dangle]` also required a `PhantomData<T>` field:
 
-```diff
+```diff,ignore
 struct OptionCell<T> {
     is_init: bool,
     value: MaybeUninit<T>,

src/code-considerations/using-unstable-lang/const-generics.md

@@ -10,15 +10,15 @@ Const generics are ok to use in public APIs, so long as they fit in the [`min_co
 
 Look out for const operations on const generics in public APIs like:
 
-```rust
+```rust,ignore
 pub fn extend_array<T, const N: usize, const M: usize>(arr: [T; N]) -> [T; N + 1] {
     ..
 }
 ```
 
 or for const generics that aren't integers, bools, or chars:
 
-```rust
+```rust,ignore
 pub fn tag<const S: &'static str>() {
     ..
 }

src/code-considerations/using-unstable-lang/specialization.md

@@ -6,7 +6,7 @@ We try to avoid leaning on specialization too heavily, limiting its use to optim
 
 As an example of how to use specialization in the standard library, consider the case of creating an `Rc<[T]>` from a `&[T]`:
 
-```rust
+```rust,ignore
 impl<T: Clone> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {
@@ -17,7 +17,7 @@ impl<T: Clone> From<&[T]> for Rc<[T]> {
 
 It would be nice to have an optimized implementation for the case where `T: Copy`:
 
-```rust
+```rust,ignore
 impl<T: Copy> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {
@@ -28,7 +28,7 @@ impl<T: Copy> From<&[T]> for Rc<[T]> {
 
 Unfortunately we couldn't have both of these impls normally, because they'd overlap. This is where private specialization can be used to choose the right implementation internally. In this case, we use a trait called `RcFromSlice` that switches the implementation:
 
-```rust
+```rust,ignore
 impl<T: Clone> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {

src/reviewer-checklist.md

@@ -6,7 +6,7 @@ Check the [getting started](./getting-started.md) guide for an introduction to d
 
 If you'd like to reassign the PR, you can:
 
-```
+```ignore
 r? @user
 ```
 
@@ -40,12 +40,12 @@ Use [`@bors`](./tools-and-bots/bors.md) to merge the pull request.
 
 To roll up:
 
-```
+```ignore
 @bors r+ rollup
 ```
 
 or just:
 
-```
+```ignore
 @bors r+
 ```

src/tools-and-bots/bors.md

@@ -6,7 +6,7 @@ PRs to the standard library aren’t merged manually using GitHub’s UI or by p
 
 You can approve a PR with:
 
-```
+```ignore
 @bors r+
 ```
 

src/tools-and-bots/crater.md

@@ -6,18 +6,18 @@
 
 You can kick off a crater run by first calling:
 
-```
+```ignore
 @bors try
 ```
 
 Once that finishes, you can then call:
 
-```
+```ignore
 @craterbot check
 ```
 
 to ensure crates compile, or:
 
-```
+```ignore
 @craterbot run mode=build-and-test
 ```

src/tools-and-bots/timer.md

@@ -4,6 +4,6 @@
 
 You can kick off a performance test using `@rust-timer`:
 
-```
+```ignore
 @bors try @rust-timer queue
 ```