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)

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.

These are deprecated in favor of print{,ln}!

Closes #9494

If an item is skipped due to it being unreachable or for some optimization, then
it shouldn't be encoded into the metadata (because it wasn't present in the
first place).

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

If an item is skipped due to it being unreachable or for some optimization, then
it shouldn't be encoded into the metadata (because it wasn't present in the
first place).

Closes #8965

extra::ringbuf: Implement method `.swap(uint, uint)` just like vector

RingBuf::swap(&mut self, i, j) swaps the element at indices `i` and `j`
if both elements are in bounds, otherwise it fails.

Closes #5416

r? anyone

This slurps up everything inside of an 'extern' block into the enclosing module
in order to document them. The documentation must be on the items themselves,
and they'll show up next to everything else on the module index pages.

Closes #5953

Takes the same approach as variants, writes a redirect index page back to the
struct with an anchor to the field in question.

Closes #9524

This also includes a fix for yielding from single-threaded schedulers where the scheduler would stop working before its work queue was empty. Fixes the deadlocks that this patch had previously.