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

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

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.

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

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)

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.

Collation of @kud1ing's work in #9511, #9512, #9513 and #9518.

This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.