tagging issue number(#10381)
disable tests on android since tcp/ip permission cannot be acquired without help of apk
temporarily disable tests on android and tagging issue number #10378
temporarily disable tests on android and tagging issue number #10379
temporarily disable tests on android and tagging issue number #10380
temporarily disable tests on android and tagging issue number #10393
Only run dsymutil on OSX in debug builds

When there are no debug symbols generated, then the program just prints an
annoying warning otherwise.

Closes #10198
Enable uv pipe tests on windows

Turns out the pipe names must have special names on windows. Once we have
special names, all the tests pass just fine.

Closes #10386
vec: with_capacity: check for overflow

Fixes #10271
doc: Don't mention TLS in condition tutorial
auto merge of #10394 : yichoi/rust/make_check_pass_android, r=brson

To enable test on android bot #9120

some tests are disabled and can be fixed further.
auto merge of #10409 : alexcrichton/rust/issue-10386, r=brson

Turns out the pipe names must have special names on windows. Once we have
special names, all the tests pass just fine.

Closes #10386
auto merge of #10417 : cmr/rust/vec_overflow, r=huonw

Fixes #10271
Add a flag to force generating toplevel crate map

As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
Optimize creation of buffered readers/writers

I was benchmarking rust-http recently, and I saw that 50% of its time was spent
creating buffered readers/writers. Albeit rust-http wasn't using
std::rt::io::buffered, but the same idea applies here. It's much cheaper to
malloc a large region and not initialize it than to set it all to 0. Buffered
readers/writers never use uninitialized data, and their internal buffers are
encapsulated, so any usage of uninitialized slots are an implementation bug in
the readers/writers.
Removed test issue-912.rs

This was marked xfail-test
According to rust's issue #912, this will not be fixed.
There's no point in keeping the test if it is never intended to pass.
Remove #[fixed_stack_segment] and #[rust_stack]

These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).

There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.

C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.

Closes #8822
Closes #10155
Decrease the default stack size back to 2MB

I increased this to 4MB when I implemented abort-on-stack-overflow for Rust
functions. Now that the fixed_stack_segment attribute is removed, no rust
function will ever reasonably request 2MB of stack (due to calling an FFI
function).

The default size of 2MB should be plenty for everyday use-cases, and tasks can
still request more stack via the spawning API.
auto merge of #10407 : alexcrichton/rust/no-fixed-stack-segment, r=brson

The commit messages have more details, but this removes all analysis and usage related to fixed_stack_segment and rust_stack attributes. It's now the assumption that we always have "enough stack" and we'll implement detection of stack overflow through other means.

The stack overflow detection is currently implemented for rust functions, but it is unimplemented for C functions (we still don't have guard pages).
Remove run-pass/issue-3907-2.rs

This test is not supposed to compile; there is an equivalent test in compile-fail/issue-3907.rs.