libstd: Check TMPDIR for android as well and if not set use '/data/local/tmp' instead of '/data/tmp'.

auto merge of #13990 : nikomatsakis/rust/issue-5527-cleanup-writeback, r=pcwalton

As part of #5527 I had to make some changes here and I just couldn't take it anymore. Refactor the writeback code. Should be functionally equivalent to the old stuff.

r? @pcwalton

auto merge of #13985 : alexcrichton/rust/libfmt, r=brson

This code does not belong in libstd, and rather belongs in a dedicated crate. In
the future, the syntax::ext::format module should move to the fmt_macros crate
(hence the name of the crate), but for now the fmt_macros crate will only
contain the format string parser.

The entire fmt_macros crate is marked #[experimental] because it is not meant
for general consumption, only the format!() interface is officially supported,
not the internals.

This is a breaking change for anyone using the internals of std::fmt::parse.
Some of the flags have moved to std::fmt::rt, while the actual parsing support
has all moved to the fmt_macros library.

[breaking-change]

std: Extract format string parsing out of libstd

This code does not belong in libstd, and rather belongs in a dedicated crate. In
the future, the syntax::ext::format module should move to the fmt_macros crate
(hence the name of the crate), but for now the fmt_macros crate will only
contain the format string parser.

The entire fmt_macros crate is marked #[experimental] because it is not meant
for general consumption, only the format!() interface is officially supported,
not the internals.

This is a breaking change for anyone using the internals of std::fmt::parse.
Some of the flags have moved to std::fmt::rt, while the actual parsing support
has all moved to the fmt_macros library.

[breaking-change]

auto merge of #14032 : pcwalton/rust/detildestr, r=alexcrichton

r? @brson

libsyntax: Remove uses of `~str` from libsyntax, and fix fallout

auto merge of #14033 : alexcrichton/rust/fix-mk-install, r=huonw

Forgot to update the installation procedure with the knowledge that libcore is
only available as an rlib, not as a dylib.

Closes #14026

auto merge of #13986 : alexcrichton/rust/box-keyword, r=thestinger

This keyword is about to be used much more often than it was a few weeks ago,
it's time to tell editors about the new keyword.

auto merge of #13835 : alexcrichton/rust/localdata, r=brson

This commit brings the local_data api up to modern rust standards with a few key
improvements:

* All functionality is now exposed as a method on the keys themselves. Instead
  of importing std::local_data, you now use "key.set()" and "key.get()".

* All closures have been removed in favor of RAII functionality. This means that
  get() and get_mut() no long require closures, but rather return
  Option<SmartPointer> where the smart pointer takes care of relinquishing the
  borrow and also implements the necessary Deref traits

* The modify() function was removed to cut the local_data interface down to its
  bare essentials (similarly to how RefCell removed set/get).

[breaking-change]

auto merge of #13814 : alexcrichton/rust/read-timeout, r=brson

This PR is an implementation of `set_timeout`, `set_read_timeout`, and `set_write_timeout` for TCP, UDP, and Unix streams (named pipes on windows).

The implementation was much more difficult than I imagined it was going to be throughout the 9 categories ({tcp, udp, unix} x {windows, unix, green}). The major snag is that libuv doesn't support canceling writes, so I chose to word the `set_write_timeout` documentation in such a way that it accomadates the behavior seen when running around with libgreen.

The first commit is from #13751, and I just included it to pre-emptively avoid rebase conflicts. The following commits are relevant to this PR. The tests aren't quite passing on windows just yet, but I should have those working by tomorrow once my VM is back up and running. For now, I wanted to see what others' thoughts were on this strategy.

Test fixes and rebase conflicts

std: Modernize the local_data api

This commit brings the local_data api up to modern rust standards with a few key
improvements:

* The `pop` and `set` methods have been combined into one method, `replace`

* The `get_mut` method has been removed. All interior mutability should be done
  through `RefCell`.

* All functionality is now exposed as a method on the keys themselves. Instead
  of importing std::local_data, you now use "key.replace()" and "key.get()".

* All closures have been removed in favor of RAII functionality. This means that
  get() and get_mut() no long require closures, but rather return
  Option<SmartPointer> where the smart pointer takes care of relinquishing the
  borrow and also implements the necessary Deref traits

* The modify() function was removed to cut the local_data interface down to its
  bare essentials (similarly to how RefCell removed set/get).

[breaking-change]

native: Implement timeouts for windows pipes

This is the last remaining networkig object to implement timeouts for. This
takes advantage of the CancelIo function and the already existing asynchronous
I/O functionality of pipes.

rustuv: Implement timeouts for unix networking

This commit implements the set{,_read,_write}_timeout() methods for the
libuv-based networking I/O objects. The implementation details are commented
thoroughly throughout the implementation.

native: Implement timeouts for unix networking

This commit has an implementation of the previous commit's timeout interface for
I/O objects on unix platforms. For implementation details, see the large comment
at the end of libnative/io/net.rs which talks about the general strategy taken.

Thankfully, all of these implementations can share code because they're
performing all the same operations.

This commit does not implement timeouts for named pipes on windows, only tcp/udp
objects on windows (which are quite similar to their unix equivalents).

std: Add I/O timeouts to networking objects

These timeouts all follow the same pattern as established by the timeouts on
acceptors. There are three methods: set_timeout, set_read_timeout, and
set_write_timeout. Each of these sets a point in the future after which
operations will time out.

Timeouts with cloned objects are a little trickier. Each object is viewed as
having its own timeout, unaffected by other objects' timeouts. Additionally,
timeouts do not propagate when a stream is cloned or when a cloned stream has
its timeouts modified.

This commit is just the public interface which will be exposed for timeouts, the
implementation will come in later commits.

mk: Fix make install

Forgot to update the installation procedure with the knowledge that libcore is
only available as an rlib, not as a dylib.

Closes #14026

auto merge of #13976 : pnkfelix/rust/fsk-fix-13965, r=alexcrichton

Fix #13965.

This commit adopts the second strategy I outlined in #13965, where the bulk of the code is still "smoke tested" (in the sense that rustdoc attempts to run it, sending all of the generated output into a locally allocated `MemWriter`).  The part of the code that is ignored (but included in the presentation) is isolated to a three-line `main` function that invokes the core rendering routine.

In the generated rustdoc output, this leads to a small break between the two code blocks, but I do not think this is a large issue.

auto merge of #13964 : alexcrichton/rust/more-buffers, r=brson

This will allow methods like read_line() on RefReader, LimitReader, etc.

auto merge of #13751 : alexcrichton/rust/io-close-read, r=brson

Two new methods were added to TcpStream and UnixStream:

    fn close_read(&mut self) -> IoResult<()>;
    fn close_write(&mut self) -> IoResult<()>;

These two methods map to shutdown()'s behavior (the system call on unix),
closing the reading or writing half of a duplex stream. These methods are
primarily added to allow waking up a pending read in another task. By closing
the reading half of a connection, all pending readers will be woken up and will
return with EndOfFile. The close_write() method was added for symmetry with
close_read(), and I imagine that it will be quite useful at some point.

Implementation-wise, librustuv got the short end of the stick this time. The
native versions just delegate to the shutdown() syscall (easy). The uv versions
can leverage uv_shutdown() for tcp/unix streams, but only for closing the
writing half. Closing the reading half is done through some careful dancing to
wake up a pending reader.

As usual, windows likes to be different from unix. The windows implementation
uses shutdown() for sockets, but shutdown() is not available for named pipes.
Instead, CancelIoEx was used with same fancy synchronization to make sure
everyone knows what's up.

cc #11165

std: Add close_{read,write}() methods to I/O

Two new methods were added to TcpStream and UnixStream:

    fn close_read(&mut self) -> IoResult<()>;
    fn close_write(&mut self) -> IoResult<()>;

These two methods map to shutdown()'s behavior (the system call on unix),
closing the reading or writing half of a duplex stream. These methods are
primarily added to allow waking up a pending read in another task. By closing
the reading half of a connection, all pending readers will be woken up and will
return with EndOfFile. The close_write() method was added for symmetry with
close_read(), and I imagine that it will be quite useful at some point.

Implementation-wise, librustuv got the short end of the stick this time. The
native versions just delegate to the shutdown() syscall (easy). The uv versions
can leverage uv_shutdown() for tcp/unix streams, but only for closing the
writing half. Closing the reading half is done through some careful dancing to
wake up a pending reader.

As usual, windows likes to be different from unix. The windows implementation
uses shutdown() for sockets, but shutdown() is not available for named pipes.
Instead, CancelIoEx was used with same fancy synchronization to make sure
everyone knows what's up.

cc #11165

auto merge of #14005 : alexcrichton/rust/extern-unsafe, r=pcwalton

Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:

    unsafe extern fn foo() {
        // ...
    }

The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.

Closes #10025

[breaking-change]

auto merge of #13726 : michaelwoerister/rust/lldb-autotests, r=alexcrichton

This pull request contains preparations for adding LLDB autotests:
+ the debuginfo tests are split into debuginfo-gdb and debuginfo-lldb
  + the `compiletest` tool is updated to support the debuginfo-lldb mode
  + tests.mk is modified to provide debuginfo-gdb and debuginfo-lldb make targets
  + GDB test cases are moved from `src/test/debug-info` to `src/test/debuginfo-gdb`
+ configure will now look for LLDB and set the appropriate CFG variables
+ the `lldb_batchmode.py` script is added to `src/etc`. It emulates GDB's batch mode

The LLDB autotests themselves are not part of this PR. Those will probable require some manual work on the test bots to make them work for the first time. Better to get these unproblematic preliminaries out of the way in a separate step.

auto merge of #13901 : alexcrichton/rust/facade, r=brson

This is the second step in implementing #13851. This PR cannot currently land until a snapshot exists with #13892, but I imagine that this review will take longer.

This PR refactors a large amount of functionality outside of the standard library into a new library, libcore. This new library has 0 dependencies (in theory). In practice, this library currently depends on these symbols being available:

* `rust_begin_unwind` and `rust_fail_bounds_check` - These are the two entry points of failure in libcore. The symbols are provided by libstd currently. In the future (see the bullets on #13851) this will be officially supported with nice error mesages. Additionally, there will only be one failure entry point once `std::fmt` migrates to libcore.
* `memcpy` - This is often generated by LLVM. This is also quite trivial to implement for any platform, so I'm not too worried about this.
* `memcmp` - This is required for comparing strings. This function is quite common *everywhere*, so I don't feel to bad about relying on a consumer of libcore to define it.
* `malloc` and `free` - This is quite unfortunate, and is a temporary stopgap until we deal with the `~` situation. More details can be found in the module `core::should_not_exist`
* `fmod` and `fmodf` - These exist because the `Rem` trait is defined in libcore, so the `Rem` implementation for floats must also be defined in libcore. I imagine that any platform using floating-point modulus will have these symbols anyway, and otherwise they will be optimized out.
* `fdim` and `fdimf` - Like `fmod`, these are from the `Signed` trait being defined in libcore. I don't expect this to be much of a problem

These dependencies all "Just Work" for now because libcore only exists as an rlib, not as a dylib.

The commits themselves are organized to show that the overall diff of this extraction is not all that large. Most modules were able to be moved with very few modifications. The primary module left out of this iteration is `std::fmt`. I plan on migrating the `fmt` module to libcore, but I chose to not do so at this time because it had implications on the `Writer` trait that I wanted to deal with in isolation. There are a few breaking changes in these commits, but they are fairly minor, and are all labeled with `[breaking-change]`.

The nastiest parts of this movement come up with `~[T]` and `~str` being language-defined types today. I believe that much of this nastiness will get better over time as we migrate towards `Vec<T>` and `Str` (or whatever the types will be named). There will likely always be some extension traits, but the situation won't be as bad as it is today.

Known deficiencies:

* rustdoc will get worse in terms of readability. This is the next issue I will tackle as part of #13851. If others think that the rustdoc change should happen first, I can also table this to fix rustdoc first.
* The compiler reveals that all these types are reexports via error messages like `core::option::Option`. This is filed as #13065, and I believe that issue would have a higher priority now. I do not currently plan on fixing that as part of #13851. If others believe that this issue should be fixed, I can also place it on the roadmap for #13851.

I recommend viewing these changes on a commit-by-commit basis. The overall change is likely too overwhelming to take in.

Test fixes and rebase conflicts

debuginfo: Split debuginfo autotests into debuginfo-gdb and debuginfo-lldb

Register new snapshots

This is the first snapshot with support to mix rlib and dylib dependencies.

core: Move Option::expect to libstd from libcore

See #14008 for more details

core: Fix an unsigned negation warning

test: Update with std => core movement

core: Get coretest working

This mostly involved frobbing imports between realstd, realcore, and the core
being test. Some of the imports are a little counterintuitive, but it mainly
focuses around libcore's types not implementing Show while libstd's types
implement Show.

core: Inherit the cell module

core: Add unwrap()/unwrap_err() methods to Result

These implementations must live in libstd right now because the fmt module has
not been migrated yet. This will occur in a later PR.

Just to be clear, there are new extension traits, but they are not necessary
once the std::fmt module has migrated to libcore, which is a planned migration
in the future.

core: Inherit the result module

The unwrap()/unwrap_err() methods are temporarily removed, and will be added
back in the next commit.

core: Remove generics from Option::expect

The prospects of a generic failure function such as this existing in libcore are
bleak, due to monomorphization not working across the crate boundary, and
allocation into a ~Any is not allowed in libcore.

The argument to expect() is now &str instead of <M: Send + Any>

[breaking-change]

core: Add a limited implementation of failure

This adds an small of failure to libcore, hamstrung by the fact that std::fmt
hasn't been migrated yet. A few asserts were re-worked to not use std::fmt
features, but these asserts can go back to their original form once std::fmt has
migrated.

The current failure implementation is to just have some symbols exposed by
std::rt::unwind that are linked against by libcore. This is an explicit circular
dependency, unfortunately. This will be officially supported in the future
through compiler support with much nicer failure messages. Additionally, there
are two depended-upon symbols today, but in the future there will only be one
(once std::fmt has migrated).

core: Bring char/finally test style up to date

core: Allow some #[deriving] in libcore

core: Implement necessary traits for ~[T]/~str

Coherence requires that libcore's traits be implemented in libcore for ~[T] and
~str (due to them being language defined types). These implementations cannot
live in libcore forever, but for now, until Heap/Box/Uniq is a lang item, these
implementations must reside inside of libcore. While not perfect
implementations, these shouldn't reside in libcore for too long.

With some form of lang item these implementations can be in a proper crate
because the lang item will not be present in libcore.

std: Remove a glob to get std to compile

core: Inherit possible string functionality

This moves as much allocation as possible from teh std::str module into
core::str. This includes essentially all non-allocating functionality, mostly
iterators and slicing and such.

This primarily splits the Str trait into only having the as_slice() method,
adding a new StrAllocating trait to std::str which contains the relevant new
allocation methods. This is a breaking change if any of the methods of "trait
Str" were overriden. The old functionality can be restored by implementing both
the Str and StrAllocating traits.

[breaking-change]

core: Inherit necessary unicode functionality

The unicode module remains private, but the normalization iterators require an
allocation, so some functionality needs to remain in libstd

core: Inherit non-allocating slice functionality

This commit adds a new trait, MutableVectorAllocating, which represents
functions on vectors which can allocate.

This is another extension trait to slices which should be removed once a lang
item exists for the ~ allocation.

core: Inherit the specific numeric modules

This implements all traits inside of core::num for all the primitive types,
removing all the functionality from libstd. The std modules reexport all of the
necessary items from the core modules.

core: Inherit what's possible from the num module

This strips out all string-related functionality from the num module. The
inherited functionality is all that will be implemented in libcore (for now).
Primarily, libcore will not implement the Float trait or any string-related
functionality.

It may be possible to migrate string parsing functionality into libcore in the
future, but for now it will remain in libstd.

All functionality in core::num is reexported in std::num.

core: Inhert ~/@/& cmp traits, remove old modules

This commit removes the std::{managed, reference} modules. The modules serve
essentially no purpose, and the only free function removed was `managed::ptr_eq`
which can be achieved by comparing references.

[breaking-change]

core: Inherit the cmp module

This removes the TotalOrd and TotalEq implementation macros, they will be added
later to the numeric modules (where the other comparison implementations live).

core: Inherit the iter module

core: Inherit the option module

core: Inherit the bool module

core: Inherit the tuple module

core: Bring clone tests up to date in style

core: Inherit the clone module

core: Inherit the unit module

core: Inherit the default module

core: Inherit the raw module

core: Inherit the any module

core: Inherit the finally module

core: Inherit the char module

core: Inherit the container module

core: Inherit the ty module

core: Inherit the ops module

core: Inherit the kinds module

core: Inherit the cast module

core: Inherit the ptr module

core: Inherit the mem module

core: Inherit the intrinsics module

mk: Add libcore

auto merge of #13832 : alexcrichton/rust/cfail-full, r=brson

Compile-fail tests for syntax extensions belong in this suite which has correct
dependencies on all artifacts rather than just the target artifacts.

Closes #13818

std: Implement the Buffer trait for some wrappers

This will allow methods like read_line() on RefReader, LimitReader, etc.

auto merge of #13967 : richo/rust/features/ICE-fails, r=alexcrichton

This change makes internal compile errors in the compile-fail tests failures.

I believe this is the correct behaviour- those tests are intended to assert that the compiler doesn't proceed, not that it explodes.

So far, it fails on 4 tests in my environment, my testcase for #13943 which is what caused me to tackle this, and 3 others:

```
failures:
    [compile-fail] compile-fail/incompatible-tuple.rs # This one is mine and not on master
    [compile-fail] compile-fail/inherit-struct8.rs
    [compile-fail] compile-fail/issue-9725.rs
    [compile-fail] compile-fail/unsupported-cast.rs
```

auto merge of #13958 : pcwalton/rust/detilde, r=pcwalton

for `~str`/`~[]`.

Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.

r? @brson or @alexcrichton or whoever

auto merge of #13914 : alexcrichton/rust/pile-o-rustdoc-fixes, r=brson

Lots of assorted things here and there, all the details are in the commits.

Closes #11712

auto merge of #13836 : jbcrail/rust/add-bitv-doc, r=alexcrichton

librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, except
for `~str`/`~[]`.

Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.

How to update your code:

* Instead of `~EXPR`, you should write `box EXPR`.

* Instead of `~TYPE`, you should write `Box<Type>`.

* Instead of `~PATTERN`, you should write `box PATTERN`.

[breaking-change]

auto merge of #13754 : alexcrichton/rust/net-experimental, r=brson

The underlying I/O objects implement a good deal of various options here and
there for tuning network sockets and how they perform. Most of this is a relic
of "whatever libuv provides", but these options are genuinely useful.

It is unclear at this time whether these options should be well supported or
not, or whether they have correct names or not. For now, I believe it's better
to expose the functionality than to not, but all new methods are added with
an #[experimental] annotation.

Ignore tests broken by failing on ICE

Fail on internal compiler errors in compile-fail

rustc: Enable writing "unsafe extern fn() {}"

Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:

    unsafe extern fn foo() {
        // ...
    }

The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.

Closes #10025

[breaking-change]

Add documentation for Bitv.

auto merge of #13892 : alexcrichton/rust/mixing-rlib-dylib-deps, r=brson

Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.

The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.

There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.

cc #10729

auto merge of #13982 : alexcrichton/rust/more-logging, r=nikomatsakis

This was accidentally left out of the recent logging improvements.

Revise doc-comments for graphviz to avoid generating files from rustdoc runs.

Fix #13965.

There is a dance here between the `main` that actually runs versus the
`main` that is printed in the output documentation.  We don't run the
latter `main`, but we do at least compile (and thus type-check) it.
It is still the responsibility of the documenter to ensure that the
signatures of `fn render` are kept in sync across the blocks.

log: Use writeln!() instead of write!()

This was accidentally left out of the recent logging improvements.

auto merge of #13960 : brandonw/rust/master, r=alexcrichton

Update the example to make the usage of `pub mod foo;` much more
apparent, as well as using an example where setting the visibility of
the module is actually necessary.

Remove error message that refactor suppresses

auto merge of #13897 : aturon/rust/issue-6085, r=bjz

The `std::bitflags::bitflags!` macro did not provide support for
adding attributes to the generates structure, due to limitations in
the parser for macros. This patch works around the parser limitations
by requiring a `flags` keyword in the `bitflags!` invocations:

    bitflags!(
        #[deriving(Hash)]
        #[doc="Three flags"]
        flags Flags: u32 {
            FlagA       = 0x00000001,
            FlagB       = 0x00000010,
            FlagC       = 0x00000100
        }
    )

The intent of `std::bitflags` is to allow building type-safe wrappers
around C-style flags APIs. But in addition to construction these flags
from the Rust side, we need a way to convert them from the C
side. This patch adds a `from_bits` function, which is unsafe since
the bits in question may not represent a valid combination of flags.

Finally, this patch changes `std::io::FilePermissions` from an exposed
`u32` representation to a typesafe representation (that only allows valid
flag combinations) using the `std::bitflags`.

Closes #6085.

Refactor writeback code. cc #5527

etc: Add box as a keyword to editor configs

This keyword is about to be used much more often than it was a few weeks ago,
it's time to tell editors about the new keyword.

auto merge of #13822 : EdorianDark/rust/master, r=cmr

New attempt to generalize stats, after #12606.
Since #12355 did not get merged, i want go get first get my change done and the try to fix sum.

Update multiple file use statement example

Update the example to make the usage of `pub mod foo;` much more
apparent, as well as using an example where setting the visibility of
the module is actually necessary.

auto merge of #13962 : luqmana/rust/al, r=alexcrichton

auto merge of #13961 : richo/rust/richo-author, r=alexcrichton

Shamelessly adds myself as a contributor.

auto merge of #13952 : aaronraimist/rust/patch-1, r=thestinger

Lower armhf target feature to v6.

auto merge of #13939 : richo/rust/docs/composability, r=thestinger

While there are various references to the work compositionality on the web, I can't find any reference to it being an actual word. My understanding is that composability is what's actually meant here anyway.

auto merge of #13925 : kballard/rust/vim_indent_bracket_fix, r=thestinger

If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.

Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.

Add Richo Healey to contributors

auto merge of #13946 : pnkfelix/rust/fsk-cleanup-proc-comment-in-guide-tasks, r=alexcrichton

Followup to some recent feedback in PR #13676.

auto merge of #13940 : edwardw/rust/refutable-match, r=pcwalton

By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing #12582 and #13027 without causing regressions
such as #13867.

Closes #13867