Contributes to rust-lang#39264

Contributes to rust-lang#39264

Fix typo

The use of a GNU C extension for bloc expressions is immaterial to the
actual problem with C macros that the section tries to show so don’t
use it and instead use a plain C way of writing the macro.

    Issue rust-lang#39059
    r? @est31

Partially fixes rust-lang#25845

book: don’t use GNU extensions in the example unnecessarily

The use of a GNU C extension for bloc expressions is immaterial to the
actual problem with C macros that the section tries to show so don’t
use it and instead use a plain C way of writing the macro which has
added benefit of being better C code (since the macro now behaves like
a function, syntax-wise).

Allow more Cell methods for non-Copy types

Clearly, `get_mut` is safe for any `T`. The other two only provide unsafe pointers anyway.

The only remaining inherent method with `Copy` bound is `get`, which sounds about right to me.

I found the order if `impl` blocks in the file a little weird (first inherent impl, then some trait impls, then another inherent impl), but didn't change it to keep the diff small.

Contributes to rust-lang#39264

…jonathandturner

Show five traits implementation in help when there are exactly five

Fixes rust-lang#39802

…n, r=est31

static recursion test added to compile-fail test suite

Issue rust-lang#39059
r? @est31

fix types in to_owned doctest

Fixes rust-lang#39831.

make doc consistent with var name

Update procedural-macros.md

Fix typo

Vec, LinkedList, VecDeque, String, and Option NatVis visualizations

I've added some basic [NatVis](https://msdn.microsoft.com/en-us/library/jj620914.aspx) visualizations for core Rust collections and types. This helps address a need filed in issue rust-lang#36503. NatVis visualizations are similar to gdb/lldb pretty printers, but for windbg and the Visual Studio debugger on Windows.

For example, Vec without the supplied NatVis looks like this in windbg using the "dx" command:
```
0:000> dx some_64_bit_vec
some_64_bit_vec                 [Type: collections::vec::Vec<u64>]
    [+0x000] buf              [Type: alloc::raw_vec::RawVec<u64>]
    [+0x010] len              : 0x4 [Type: unsigned __int64]
```

With the NatVis, the elements of the Vec are displayed:
```
0:000> dx some_64_bit_vec
some_64_bit_vec                 : { size=0x4 } [Type: collections::vec::Vec<u64>]
    [<Raw View>]     [Type: collections::vec::Vec<u64>]
    [size]           : 0x4 [Type: unsigned __int64]
    [capacity]       : 0x4 [Type: unsigned __int64]
    [0]              : 0x4 [Type: unsigned __int64]
    [1]              : 0x4f [Type: unsigned __int64]
    [2]              : 0x1a [Type: unsigned __int64]
    [3]              : 0x184 [Type: unsigned __int64]
```

In fact, the vector can be treated as an array by the NatVis expression evaluator:
```
0:000> dx some_64_bit_vec[2]
some_64_bit_vec[2] : 0x1a [Type: unsigned __int64]
```

In general, it works with any NatVis command that understands collections, such as NatVis LINQ expressions:
```
0:000> dx some_64_bit_vec.Select(x => x * 2)
some_64_bit_vec.Select(x => x * 2)
    [0]              : 0x8
    [1]              : 0x9e
    [2]              : 0x34
    [3]              : 0x308
```

std::string::String is implemented, as well:
```
0:000> dv
    hello_world = "Hello, world!"
          empty = ""
            new = ""
0:000> dx hello_world
hello_world                 : "Hello, world!" [Type: collections::string::String]
    [<Raw View>]     [Type: collections::string::String]
    [size]           : 0xd [Type: unsigned __int64]
    [capacity]       : 0xd [Type: unsigned __int64]
    [0]              : 72 'H' [Type: char]
    [1]              : 101 'e' [Type: char]
...
    [12]             : 33 '!' [Type: char]
0:000> dx empty
empty                 : "" [Type: collections::string::String]
    [<Raw View>]     [Type: collections::string::String]
    [size]           : 0x0 [Type: unsigned __int64]
    [capacity]       : 0x0 [Type: unsigned __int64]

```

VecDeque and LinkedList are also implemented.

My biggest concern is the implementation for Option due to the different layouts it can receive based on whether the sentinel value can be embedded with-in the Some value or must be stored separately.

It seems to work, but my testing isn't exhaustive:
```
0:000> dv
          three = { Some 3 }
           none = { None }
         no_str = { None }
       some_str = { Some "Hello!" }
0:000> dx three
three                 : { Some 3 } [Type: core::option::Option<i32>]
    [<Raw View>]     [Type: core::option::Option<i32>]
    [size]           : 0x1 [Type: ULONG]
    [value]          : 3 [Type: int]
    [0]              : 3 [Type: int]
0:000> dx none
none                 : { None } [Type: core::option::Option<i32>]
    [<Raw View>]     [Type: core::option::Option<i32>]
    [size]           : 0x0 [Type: ULONG]
    [value]          : 4 [Type: int]
0:000> dx no_str
no_str                 : { None } [Type: core::option::Option<collections::string::String>]
    [<Raw View>]     [Type: core::option::Option<collections::string::String>]
    [size]           : 0x0 [Type: ULONG]
0:000> dx some_str
some_str                 : { Some "Hello!" } [Type: core::option::Option<collections::string::String>]
    [<Raw View>]     [Type: core::option::Option<collections::string::String>]
    [size]           : 0x1 [Type: ULONG]
    [value]          : 0x4673df710 : "Hello!" [Type: collections::string::String *]
    [0]              : "Hello!" [Type: collections::string::String]
```

For now all of these visualizations work in windbg, but I've only gotten the visualizations in libcore.natvis working in the VS debugger. My priority is windbg, but somebody else may be interested in investigating the issues related to VS.

You can load these visualizations into a windbg sessions using the .nvload command:
```
0:000> .nvload ..\rust\src\etc\natvis\libcollections.natvis; .nvload ..\rust\src\etc\natvis\libcore.natvis
Successfully loaded visualizers in "..\rust\src\etc\natvis\libcollections.natvis"
Successfully loaded visualizers in "..\rust\src\etc\natvis\libcore.natvis"
```

There are some issues with the symbols that Rust and LLVM conspire to emit into the PDB that inhibit debugging in windbg generally, and by extension make writing visualizations more difficult. Additionally, there are some bugs in windbg itself that complicate or disable some use of the NatVis visualizations for Rust. Significantly, due to NatVis limitations in windbg around allowable type names, you cannot write a visualization for [T] or str. I'll report separate issues as I isolate them.

In the near term, I hope to fill out these NatVis files with more of Rust's core collections and types. In the long run, I hope that we can ship NatVis files with crates and streamline their deployment when debugging Rust programs on windows.

sys/mod doc update and mod import order adjust

* Some doc updates.
* Racer currently use the first mod it finds regardless of cfg attrs. Moving #[cfg(unix)] up should be a temporary tweak that works as expected for more people.

Fix typo

use bash when invoking dist shell scripts on solaris

Partially fixes rust-lang#25845

A separate, trivial fix is needed to the rust-installer scripts to completely resolve this issue.

Fix parameter to GetUserProfileDirectoryW