rustdoc: Allow private modules be included in docs

Made it so that what passes are used is passed onto the renderer so it
can intelligently deal with private modules.
auto merge of #18822 : scialex/rust/better-rustdoc, r=alexcrichton

Changed `rustdoc` so that if we do not have the `strip-private` pass
enabled private modules will be included in the generated documentation

I added this because it is useful to be able to read the documentation in the very nice `rustdoc` web interface when doing internal work on a project. In this case we want the `rustdoc` to include modules that are hidden from consumers. Since this is not currently possible I added it here.
auto merge of #18603 : brson/rust/stdchar, r=aturon

* Deprecate the free functions in favor of methods, except the two ctors `from_u32` and `from_digit`, whose methods are deprecated.
* Mark the `Char` and `UnicodeChar` traits experimental until we decide for sure that we won't have some sort of inherent methods for primitives.
* The `UnicodeChar` methods related to numerics are now called e.g. `is_numeric` to match the 'numeric' unicode character class, and the `*_digit_radix` methods on `Char` now just called `*_digit`.
* `len_utf8_bytes` -> `len_utf8`
* Converted methods to take self by-value
* Converted `escape_default` and `escape_unicode` to iterators over chars.
* Renamed `is_XID_start`, `is_XID_continue` to `is_xid_start`, `is_xid_continue` to match conventions

This also converts `encode_utf8` and `encode_utf16` to return iterators. I suspect this is not the final form of these methods. Perf is worse (numbers in the commit). Many of the uses ended up being awkward, copying into a buffer then writing that buffer to a `Writer`. It might be more appropriate for these to return `Reader`s instead, but that type is defined in `std`.

Note: although I *did* add the `from_u32` ctor to the `Char` trait, I deprecated it again later, preferring the free ctors.

I've been sitting on this for a while.

cc @aturon
auto merge of #19117 : jmesmon/rust/mk-cfg-suffix, r=cmr

Right now we'll end up globbing them into the accepted targets and (ever worse) they will override the make variables of real target files because we `include`d everything in that directory.

As a side effect, editors get a better hint on file types.
auto merge of #19122 : Kintaro/rust/remove_struct_variant, r=jakub-

The struct_variant is not gated anymore. This commit just removes it and the resulting warnings when compiling rust. Now compiles with the snapshot from 11/18 (as opposed to PR #19014)
removed struct_variant feature from tests
rollup merge of #19094: alexcrichton/rm-std-local-data

This commit removes the `std::local_data` module in favor of a new `std::thread_local`
module providing thread local storage. The module provides two variants of TLS:
one which owns its contents and one which is based on scoped references. Each
implementation has pros and cons listed in the documentation.

Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.

This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new tls system like so:

    thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None)))

The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.

[rfc]: https://github.com/rust-lang/rfcs/pull/461
[breaking-change]
rollup merge of #19124: Kintaro/remove_test_struct_variants

Removed usage of struct_variant feature from all tests.
rollup merge of #19125: chris-morgan/vim-prelude-2014-11-20
rollup merge of #19132: sinistersnare/patch-1

Just used Githubs edit view, so I hope this works...
rollup merge of #19133: nodakai/run-make-tests-missing-extracflags

Missing `$(EXTRACFLAGS)` resutled in compile failures.
rollup merge of #19134: sinistersnare/patch-2

Vec<T> can index now so its a useless conversion.
rollup merge of #19136: alfie/master

An example of how type definitions work would be handy
rollup merge of #19137: tbu-/pr_refcell_unsafety
rollup merge of #19144: michaelwoerister/lldb-scripts

This PR adds the `rust-lldb` script (feel free to bikeshed about the name).
The script will start LLDB and, before doing anything else, load [LLDB type summaries](http://lldb.llvm.org/varformats.html) that will make LLDB print values with Rust syntax. Just use the script like you would normally use LLDB:

```
rust-lldb executable-to-debug --and-any-other-commandline --args
```
The script will just add one additional commandline argument to the LLDB invocation and pass along the rest of the arguments to LLDB after that.

Given the following program...
```rust
fn main() {
	let x = Some(1u);
	let y = [0, 1, 2i];
	let z = (x, y);

	println!("{} {} {}", x, y, z);
}
```
...*without* the 'LLDB type summaries', values will be printed something like this...
```
(lldb) p x
(core::option::Option<uint>) $3 = {
   = (RUST$ENUM$DISR = Some)
   = (RUST$ENUM$DISR = Some, 1)
}
(lldb) p y
(long [3]) $4 = ([0] = 0, [1] = 1, [2] = 2)
(lldb) p z
((core::option::Option<uint>, [int, ..3])) $5 = {
   = {
     = (RUST$ENUM$DISR = Some)
     = (RUST$ENUM$DISR = Some, 1)
  }
   = ([0] = 0, [1] = 1, [2] = 2)
}
```
...*with* the 'LLDB type summaries', values will be printed like this:
```
(lldb) p x
(core::option::Option<uint>) $0 = Some(1)
(lldb) p y
(long [3]) $1 = [0, 1, 2]
(lldb) p z
((core::option::Option<uint>, [int, ..3])) $2 = (Some(1), [0, 1, 2])
```

The 'LLDB type summaries' used by the script have been in use for a while in the LLDB autotests but I still consider them to be of alpha-version quality. If you see anything weird when you use them, feel free to file an issue.

The script will use whatever Rust "installation" is in PATH, so whichever `rustc` will be called if you type `rustc` into the console, this is the one that the script will ask for the LLDB extension module location. The build system will take care of putting the script and LLDB python module in the right places, whether you want to use the stage1 or stage2 compiler or the one coming with `make install` / `rustup.sh`.

Since I don't have much experience with the build system, Makefiles and shell scripts, please look these changes over carefully.
Rename unwrap functions to into_inner

This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.

[rfc]: https://github.com/rust-lang/rfcs/pull/430
[breaking-change]

Closes #13159
cc #19091
rollup merge of #19146: gereeter/reference-borrow

This should be a more general version of #19131.
rollup merge of #19149: alexcrichton/issue-19091
rollup merge of #19150: Manishearth/find-doc

It's useful to know this (opens up a bunch of other opportunities especially whilst parsing)
rollup merge of #19152: alexcrichton/issue-17863