r? strcat 

(please double check that it fixes things on your chroot, if possible, before approval)

Fix #9531

They're getting smaller each time though!

The highlight of this round is source files in documentation. Still trying to figure out the best syntax-highlighting solution.

This removes the internal type representation of an `External` type and instead
relies on passing around DefId structures and interpreting them accordingly.

Progress on #9539, but there's still the problem of a crate => url mapping.

std::vec: Sane implementations for connect_vec and concat_vec

Avoid unnecessary copying of subvectors, and calculate the needed space
beforehand. These implementations are simple but better than the
previous.

Also only implement it once, for all `Vector<T>` using:

    impl<'self, T: Clone, V: Vector<T>> VectorVector<T> for &'self [V]

Closes #9581

change formula (other solution could be using abs()).

Small change that suppresses a warning because of an unused import.

std::vec::{concat, connect, concat_slices, connect_slices} are replaced
by the already existing trait methods .concat_vec() and .connect_vec().

Avoid unnecessary copying of subvectors, and calculate the needed space
beforehand. These implementations are simple but better than the
previous.

Also only implement it once, for all `Vector<T>` using:

    impl<'self, T: Clone, V: Vector<T>> VectorVector<T> for &'self [V]

performance improved according to the bench test:

    before
    test vec::bench::concat ... bench: 74818 ns/iter (+/- 408)
    test vec::bench::connect ... bench: 87066 ns/iter (+/- 376)

    after
    test vec::bench::concat ... bench: 17724 ns/iter (+/- 126)
    test vec::bench::connect ... bench: 18353 ns/iter (+/- 691)

Closes #9581

std::vec: Use a valid value as lifetime dummy in iterator

The current implementation uses `&v[0]` for the lifetime struct field,
but that is a dangling pointer for iterators derived from zero-length
slices.

Example:

    let v: [int, ..0] = [];  println!("{:?}", v.iter())

    std::vec::VecIterator<,int>{ptr: (0x7f3768626100 as *()), end: (0x7f3768626100 as *()), lifetime: &139875951207128}

To replace this parameter, use a field of type `Option<&'self ()>`
that is simply initialized with `None`, but still allows the iterator to
have a lifetime parameter.

Instead use &mut everywhere as much as possible and then reorganize lots of code
to get past the borrow checker.

All items have source links back to their actual code. Source files can be
omitted with the doc(html_no_source) attribute on the crate. Currently there is
no syntax highlighting, but that will come with syntax highlighting with all
other snippets.

Closes #2072

r? @metajack Towards #7401

This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org

This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org

Closes #9566

It's just a waste of disk space and it can be done just as well in JS.

As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.

This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).

Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.

As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.

This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).

Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.

Towards #7401

The 0.8 release was cut, down with printf!

Closes #9494

Commit messages have the details, mostly just knocking out more low-hanging-fruit type issues.

This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.

For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.

The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.

Closes #8651
Closes #3547
Closes #2537
Closes #6971
Closes #9222

that is, if super trait had more methods, tnen subtrait, compiling would fail. I simply forgot to update
variable name. Updated test case , too.

One of the downsides with `c_str` is that it always forces an allocation, and so this could add unnecessary overhead to various calls. This PR implements one of the suggestions @graydon made in #8296 for `vec.with_c_str` in that for a short string can use a small stack array instead of a malloced array for our temporary c string. This ends up being twice as fast for small strings.

There are two things to consider before landing this commit though. First off, I arbitrarily picked the stack array as 32 bytes, and I'm not sure if this a reasonable amount or not. Second, there is a risk that someone can keep a reference to the interior stack pointer, which could cause mayhem if someone were to dereference the pointer. Since we also can easily grab and return interior pointers to vecs though, I don't think this is that much of an issue.

This also fixes a bug in `vec.with_c_str_unchecked` where we
were not calling `.to_c_str_unchecked()` for long strings.

before:

test c_str::bench::bench_with_c_str_unchecked_long ... bench: 361 ns/iter (+/- 9)
test c_str::bench::bench_with_c_str_unchecked_medium ... bench: 75 ns/iter (+/- 2)
test c_str::bench::bench_with_c_str_unchecked_short ... bench: 60 ns/iter (+/- 9)

after:

test c_str::bench::bench_with_c_str_unchecked_long ... bench: 362 ns/iter (+/-
test c_str::bench::bench_with_c_str_unchecked_medium ... bench: 30 ns/iter (+/- 7)
test c_str::bench::bench_with_c_str_unchecked_short ... bench: 12 ns/iter (+/- 4)

This matches @graydon's recommendation.

The documentation for `.with_c_str()` already says that the pointer
will be deallocated before returning from the function.

This now makes it unsafe to save the pointer returned by .with_c_str
as that pointer now may be pointing at a stack allocated array.

I arbitrarily chose 32 bytes as the length of the stack vector, and
so it might not be the most optimal size.

before:

test c_str::bench::bench_with_c_str_long ... bench: 539 ns/iter (+/- 91)
test c_str::bench::bench_with_c_str_medium ... bench: 97 ns/iter (+/- 2)
test c_str::bench::bench_with_c_str_short ... bench: 70 ns/iter (+/- 5)

after:

test c_str::bench::bench_with_c_str_long ... bench: 542 ns/iter (+/- 13)
test c_str::bench::bench_with_c_str_medium ... bench: 53 ns/iter (+/- 6)
test c_str::bench::bench_with_c_str_short ... bench: 19 ns/iter (+/- 0)