doc: Modernize FAQs just slightly
extra::test: add an opaque function to assist with accurate
benchmarking.

This allows a result to be marked as "used" by passing it to a function
LLVM cannot see inside. By making `iter` generic and using this
`black_box` on the result benchmarks can get this behaviour simply by
returning their computation.
arena: use the generic `bh.iter` to stop the benchmarks being DCE'd.

Before:

    test test::bench_nonpod_nonarena  ... bench:        62 ns/iter (+/- 6)
    test test::bench_pod_nonarena     ... bench:         0 ns/iter (+/- 0)

After:

    test test::bench_nonpod_nonarena  ... bench:       158 ns/iter (+/- 11)
    test test::bench_pod_nonarena     ... bench:        48 ns/iter (+/- 2)

The other tests show no change, but are adjusted to use the generic
return value of `.iter` anyway so that this doesn't change in future.
Fix infinite loop in MemReader::read_until.
Fix infinite loop in BufReader::read_until.
auto merge of #12105 : huonw/rust/bench-black-box, r=alexcrichton

This allows a result to be marked as "used" by passing it to a function
LLVM cannot see inside (unless LTO is enabled).

Closes #8261.
auto merge of #12114 : brson/rust/faqs, r=cmr

These are ancient. I removed a bunch of questions that are less relevant - or completely unrelevant, updated other entries, and removed things that are already better expressed elsewhere.
Expand the testing guide to cover optimizations, benchmarks and how to
be more precise about what's being benchmarked.

Also, reorganise the layout a bit, to put examples directly in their
sections.
auto merge of #12106 : qpliu/rust/memreader-fill-eof, r=sfackler

I don't know if anything depends on MemReader::fill returning an empty slice instead of EndOfFile, but I'm pretty sure that MemReader::read_until should not go into an infinite loop.
Add new syntax extension fourcc!()

fourcc!() allows you to embed FourCC (or OSType) values that are
evaluated as u32 literals. It takes a 4-byte ASCII string and produces
the u32 resulting in interpreting those 4 bytes as a u32, using either
the platform-native endianness, or explicitly as big or little endian.
Converted fourcc! to loadable syntax extension
Default fourcc! to big-endian.

It was decided that a consistent result across platforms would be the
most useful and least surprising. A "target" option has been added to
get the old behaviour of using the target platform's endianess.
Allow codepoints 128-255 in fourc!!

Codepoints with those values will be interpreted as bytes with their
raw codepoint value. ('\xAB' -> 0xABu8, etc.) Codepoints > 255 remain
forbidden.
std::io: Add `Chars` iterator for Buffer.

Add `std::io::Chars` iterator and `Buffer#chars()` method
auto merge of #12034 : dguenther/rust/fourcc, r=alexcrichton

I was looking into #9303 and was curious if this would still be valuable. @kballard had already done 99% of the work, so I brought the branch up to date and added a feature gate. Any feedback would be appreciated; I wasn't sure if this should be set up as a syntax extension with `#[macro_registrar]`, and if so, where it should be located.

Original PR is here: #9255

TODO:
* [x] Convert to loadable syntax extension
* [x] Default to big endian
* [x] Add `target` identifier
* [x] Expand to include code points 128-255
std: Add init and uninit to mem. Replace direct intrinsic usage
std: Add move_val_init to mem. Replace direct intrinsic usage
std: Move byteswap functions to mem
std: Make mem's doc slightly more accurate
auto merge of #12117 : nikomatsakis/rust/issue-11913-borrow-in-aliasable-loc, r=pcwalton

Repair a rather embarassingly obvious hole that I created as part of #9629. In particular, prevent `&mut` borrows of data in an aliasable location. This used to be prevented through the restrictions mechanism, but in #9629 I modified those rules incorrectly. 

r? @pcwalton

Fixes #11913