auto merge of #12286 : sfackler/rust/no-conditions, r=alexcrichton

auto merge of #12283 : kballard/rust/env-args-bytes, r=erickt

Change `os::args()` and `os::env()` to use `str::from_utf8_lossy()`.
Add new functions `os::args_as_bytes()` and `os::env_as_bytes()` to retrieve the args/env as byte vectors instead.

The existing methods were left returning strings because I expect that the common use-case is to want string handling.

Fixes #7188.

auto merge of #12230 : DaGenix/rust/io-decorator-changes, r=sfackler

I created RefReader and RefWriter structs that wrap a mutable reference to a Reader or Writer value. This works exactly like the ByRef struct in the iter module and allows passing a reference to a Reader or Writer to function expecting a Reader or Writer by value with the caller retaining ownership to the original value.

I also modified LimitReader to take the wrapped Reader by value instead of by reference.

@sfackler

Remove broken link to old conditions tutorial

Update LimitReader to take the Reader to wrap by value

Create RefReader and RefWriter adaptor structs

RefReader and RefWriter allow a caller to pass a Reader or Writer
instance by reference to generic functions that are expecting arguments
by value.

Use str::from_utf8_lossy() for os::env() and friends

Parse the environment by default with from_utf8_lossy. Also provide
byte-vector equivalents (e.g. os::env_as_bytes()).

Unfortunately, setenv() can't have a byte-vector equivalent because of
Windows support, unless we want to define a setenv_bytes() that fails
under Windows for non-UTF8 (or non-UTF16).

Use str::from_utf8_lossy() in os::args(), add os::args_as_bytes()

os::args() was using str::raw::from_c_str(), which would assert if the
C-string wasn't valid UTF-8. Switch to using from_utf8_lossy() instead,
and add a separate function os::args_as_bytes() that returns the ~[u8]
byte-vectors instead.

Add c_str::CString.as_bytes_no_nul()

auto merge of #12274 : brson/rust/mkfiles, r=alexcrichton

I've been working on binary installers and ended up taking this detour, which does a few things:

* It expands the documentation on the build system with new comments in Makefile.in
* It displays some of that documentation via `make help`
* Removes some unused and broken snapshot code
* Adds `NO_MKFILE_DEPS` to convenience makefile hacking
* Moves almost all of Makefile.in to files in `mk/`

The documentation provided by `make help` and its implementation are somewhat quirky.

auto merge of #12276 : alexcrichton/rust/issue-8449, r=kballard

This was just waiting for compiler-rt support, which was added in #12027

Closes #8449

Enable 64-bit checked multiplication on 32-bit

This was just waiting for compiler-rt support, which was added in #12027

Closes #8449

mk: Address review feedback

auto merge of #12277 : alexcrichton/rust/fix-rustdoc-render, r=huonw

The std macros used to be injected with a filename of "<std-macros>", but macros
are now injected with a filename of "<{} macros>" where `{}` is filled in with
the crate name. This updates rustdoc to understand this new system so it'll
render source more frequently.

mk: Move version info to top of main.mk

Just so it's easier to find.

mk: Improve build system help commands

mk: Add NO_MKFILE_DEPS for turning off rebuild from makefile changes

mk: Move most of Makefile.in to .mk files

Because the build system treats Makefile.in and the .mk files slightly
differently (.in is copied, .mk are included), this makes the system
more uniform. Fewer build system changes will require a complete
reconfigure.

mk: Remove the concept of 'snapshot transitions'

This way of doing snapshots hasn't been used since 2011.

mk: Add some serious documentation and 'make help'

'make help' is implemented in a fairly ridiculous way, using awk
to parse comments out of Makefile.in and displaying them.

auto merge of #12271 : kballard/rust/vim-extern-crate, r=huonw

Add crate keyword to gedit language spec

Add crate to emacs and kate modefiles

auto merge of #12195 : kballard/rust/rustdoc-strip-impls-of-stripped, r=cmr

Strip trait impls for types that are stripped either due to the strip-hidden or strip-private passes.

This fixes the search index including trait methods on stripped structs (which breaks searching), and it also removes private types from the implementors list of a trait.

Fixes #9981 and #11439.

Update restrictions on rustdoc source rendering

The std macros used to be injected with a filename of "<std-macros>", but macros
are now injected with a filename of "<{} macros>" where `{}` is filled in with
the crate name. This updates rustdoc to understand this new system so it'll
render source more frequently.

auto merge of #12267 : alexcrichton/rust/rollup, r=alexcrichton

The last commit has the closed PRs

Add CheckedDiv to vim syntax

Update vim syntax for extern crate

Test fixes and rebase conflicts from rollups

PRs closed as part of this:

Closes #12212 r=alexcrichton
Closes #12215 r=brson
Closes #12246 r=pcwalton
Closes #12247 r=cmr
Closes #12251 r=brson
Closes #12255 r=alexcrichton
Closes #12257 r=alexcrichton
Closes #12258 r=huonw
Closes #12259 r=huonw
Closes #12263 r=kballard
Closes #12269 r=alexcrichton

tutorial: stronger wording in build instructions

rustdoc: Strip impls of traits on #[doc(hidden)] types

In the strip-hidden pass, record all types that were stripped, and make
a second pass stripping all impls of traits for these types.

rustdoc: Strip impls of stripped private types

In strip-private, also strip impls of traits for private types. This
fixes the search index so searching for "drop", "eq", etc doesn't throw
an exception.

Add MKFILE_DEPS to compiler-rt target

Currently when you run `make -jN` it's likely that you'll remove compiler-rt and
then it won't get cp'd back into the right place. I believe the reason for this
is that the compiler-rt library target never got updated so make decided it
never needed to copy the files back into place. The files were all there at the
beginning of `make`, but then we may clean out the stage0 versions if we unzip
the snapshot again.

auto merge of #12205 : alexcrichton/rust/nodefaultlibs, r=brson

This will hopefully bring us closer to #11937. We're still using gcc's idea of
"startup files", but this should prevent us from leaking in dependencies that we
don't quite want (libgcc for example once compiler-rt is what we use).

Invoke gcc with -nodefaultlibs

This will hopefully bring us closer to #11937. We're still using gcc's idea of
"startup files", but this should prevent us from leaking in dependencies that we
don't quite want (libgcc for example once compiler-rt is what we use).

Removed the obsolete ast::CallSugar (previously used by `do`).

Expand ItemDecorator extensions in all contexts

Now that fold_item can return multiple items, this is pretty trivial. It
also recursively expands generated items so ItemDecorators can generate
items that are tagged with ItemDecorators!

Closes #4913

Add test for #8860

Removed libextra dependency from libsyntax.

Add function doc comments for extra::url::*

Ensure an error is raised on infinite recursion

Don't copy &Trait and &mut Trait to temporaries for every call.

extra: Capture stdout/stderr of tests by default

When tests fail, their stdout and stderr is printed as part of the summary, but
this helps suppress failure messages from #[should_fail] tests and generally
clean up the output of the test runner.

return value/use extra::test::black_box in benchmarks

auto merge of #12207 : alexcrichton/rust/up-llvm, r=sfackler

Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.

This also introduces a new commit on top of our stack of patches to fix a mingw32 build issue. I have submitted the patch upstream: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140210/204653.html

I verified that this builds on the try bots, which amazes me because I think that c++11 is turned on now, but I guess we're still lucky!

Closes #10613 (pcwalton's patch landed)
Closes #11992 (llvm has removed these options)

Upgrade LLVM

Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.

auto merge of #12234 : sfackler/rust/restructure-item-decorator, r=huonw

The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.

@huonw

auto merge of #12192 : luqmana/rust/fix-cross, r=alexcrichton

Fix some fall out from the big command line option changes.

auto merge of #12186 : alexcrichton/rust/no-sleep-2, r=brson

Any single-threaded task benchmark will spend a good chunk of time in `kqueue()` on osx and `epoll()` on linux, and the reason for this is that each time a task is terminated it will hit the syscall. When a task terminates, it context switches back to the scheduler thread, and the scheduler thread falls out of `run_sched_once` whenever it figures out that it did some work.

If we know that `epoll()` will return nothing, then we can continue to do work locally (only while there's work to be done). We must fall back to `epoll()` whenever there's active I/O in order to check whether it's ready or not, but without that (which is largely the case in benchmarks), we can prevent the costly syscall and can get a nice speedup.

I've separated the commits into preparation for this change and then the change itself, the last commit message has more details.

auto merge of #12162 : eddyb/rust/ast-map-cheap-path, r=nikomatsakis

Refactored ast_map and friends, mainly to have Paths without storing them.

Tweak ItemDecorator API

The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.

auto merge of #12256 : brson/rust/android, r=alexcrichton

Android bot has been having some problems. A few details in the commits.

Stop looping on error waiting for android test results

These seem to be causing iloops on the bots. Let's rather see the errors.

compiletest: Run all android tests serially

This is an attempt to isolate test failures on the bots. It may also
eliminate problems with the emulators breaking by reducing the chance
of OOM.

auto merge of #12172 : alexcrichton/rust/green-improvements, r=brson

These commits pick off some low-hanging fruit which were slowing down spawning green threads. The major speedup comes from fixing a bug in stack caching where we never used any cached stacks!

The program I used to benchmark is at the end. It was compiled with `rustc --opt-level=3 bench.rs --test` and run as `RUST_THREADS=1 ./bench --bench`. I chose to use `RUST_THREADS=1` due to #11730 as the profiles I was getting interfered too much when all the schedulers were in play (and shouldn't be after #11730 is fixed). All of the units below are in ns/iter as reported by `--bench` (lower is better).

|               | green | native | raw    |
| ------------- | ----- | ------ | ------ |
| osx before    | 12699 | 24030  | 19734  |
| linux before  | 10223 | 125983 | 122647 |
| osx after     |  3847 | 25771  | 20835  |
| linux after   |  2631 | 135398 | 122765 |

Note that this is *not* a benchmark of spawning green tasks vs native tasks. I put in the native numbers just to get a ballpark of where green tasks are. This is benchmark is *clearly* benefiting from stack caching. Also, OSX is clearly not 5x faster than linux, I think my VM is just much slower.

All in all, this ended up being a nice 4x speedup for spawning a green task when you're using a cached stack.

```rust
extern mod extra;
extern mod native;
use std::rt::thread::Thread;

#[bench]
fn green(bh: &mut extra::test::BenchHarness) {
    let (p, c) = SharedChan::new();
    bh.iter(|| {
        let c = c.clone();
        spawn(proc() {
            c.send(());
        });
        p.recv();
    });
}

#[bench]
fn native(bh: &mut extra::test::BenchHarness) {
    let (p, c) = SharedChan::new();
    bh.iter(|| {
        let c = c.clone();
        native::task::spawn(proc() {
            c.send(());
        });
        p.recv();
    });
}

#[bench]
fn raw(bh: &mut extra::test::BenchHarness) {
    bh.iter(|| {
        Thread::start(proc() {}).join()
    });
}
```

Remove two allocations from spawning a green task

Two unfortunate allocations were wrapping a proc() in a proc() with
GreenTask::build_start_wrapper, and then boxing this proc in a ~proc() inside of
Context::new(). Both of these allocations were a direct result from two
conditions:

1. The Context::new() function has a nice api of taking a procedure argument to
   start up a new context with. This inherently required an allocation by
   build_start_wrapper because extra code needed to be run around the edges of a
   user-provided proc() for a new task.

2. The initial bootstrap code only understood how to pass one argument to the
   next function. By modifying the assembly and entry points to understand more
   than one argument, more information is passed through in registers instead of
   allocating a pointer-sized context.

This is sadly where I end up throwing mips under a bus because I have no idea
what's going on in the mips context switching code and don't know how to modify
it.

Closes #7767
cc #11389

Don't require an allocation for on_exit messages

Instead, use an enum to allow running both a procedure and sending the task
result over a channel. I expect the common case to be sending on a channel (e.g.
task::try), so don't require an extra allocation in the common case.

cc #11389

Don't allocate in LocalHeap::new()

One of these is allocated for every task, trying to cut down on allocations

cc #11389

Fix a bug where cached stacks weren't re-used

The condition was the wrong direction and it also didn't take equality into
account. Tests were added for both cases.

For the small benchmark of `task::try(proc() {}).unwrap()`, this takes the
iteration time on OSX from 15119 ns/iter to 6179 ns/iter (timed with
RUST_THREADS=1)

cc #11389

auto merge of #12061 : pongad/rust/delorderable, r=cmr

#12057

Removed num::Orderable

auto merge of #12017 : FlaPer87/rust/replace-mod-crate, r=alexcrichton

The first setp for #9880 is to add a new `crate` keyword. This PR does exactly that. I took a chance to refactor `parse_item_foreign_mod` and I broke it down into 2 separate methods to isolate each feature.

The next step will be to push a new stage0 snapshot and then get rid of all `extern mod` around the code.

auto merge of #12248 : alexcrichton/rust/rollup, r=alexcrichton

This passed `make check` locally, so hopefully it passes on bors!

mk: Fix non-android cross builds.

Rebase conflicts from this giant stack of patches

List of PRs contained in this rollup:

Closes #12167 r=alexcrichton
Closes #12200 r=alexcrichton
Closes #12206 r=pcwalton
Closes #12209 r=huonw
Closes #12211 r=pcwalton
Closes #12217 r=brson
Closes #12218 r=alexcrichton
Closes #12220 r=alexcrichton
Closes #12222 r=kballard
Closes #12225 r=alexcrichton
Closes #12227 r=kballard
Closes #12237 r=alexcrichton
Closes #12240 r=kballard

Lift $dst outside the closure in write!

If you were writing to something along the lines of `self.foo` then with the new
closure rules it meant that you were borrowing `self` for the entirety of the
closure, meaning that you couldn't format other fields of `self` at the same
time as writing to a buffer contained in `self`.

By lifting the borrow outside of the closure the borrow checker can better
understand that you're only borrowing one of the fields at a time. This had to
use type ascription as well in order to preserve trait object coercions.

remove duplicate function from std::ptr (is_null, is_not_null, offset, mut_offset)

Register new snapshots

mk: make NO_REBUILD more forceful and more general.

Previously crates like `green` and `native` would still depend on their
parents when running `make check-stage2-green NO_REBUILD=1`, this
ensures that they only depend on their source files.

Also, apply NO_REBUILD to the crate doc tests, so, for example,
`check-stage2-doc-std` will use an already compiled `rustdoc` directly.

Relax an assertion in start_selection()

It asserted that the previous count was always nonnegative, but DISCONNECTED is
a valid value for it to see. In order to continue to remember to store
DISCONNECTED after DISCONNECTED was seen, I also added a helper method.

Closes #12226

std::comm: replace Handle.id with a method.

The `id` shouldn't be changed by external code, and exposing it publicly
allows to be accidentally changed.

Also, remove the first element special case in the `select!` macro.

Add documentation for conditional-compilation

This documents in-source conditions using #[cfg(...)] and configurations
pre-defined by the compiler.

Fix #7962.

Add some missing Show implementations in libstd

Move base64 and hex from libextra to libserialize

Remove a source of O(n^2) running time in bigints.

::num::bigint, Remove a source of O(n^2) running time in `fn shr_bits`.

I'll cut to the chase: On my laptop, this brings the running time on
`pidigits 2000` (from src/test/bench/shootout-pidigits.rs) from this:
```
% time ./pidigits 2000 > /dev/null

real 0m7.695s
user 0m7.690s
sys 0m0.005s
```
to this:
```
% time ./pidigits 2000 > /dev/null

real 0m0.322s
user 0m0.318s
sys 0m0.004s
```

The previous code was building up a vector by repeatedly making a
fresh copy for each element that was unshifted onto the front,
yielding quadratic running time.  This fixes that by building up the
vector in reverse order (pushing elements onto the end) and then
reversing it.

(Another option would be to build up a zero-initialized vector of the
desired length and then installing all of the shifted result elements
into their target index, but this was easier to hack up quickly, and
yields the desired asymptotic improvement.  I have been thinking of
adding a `vec::from_fn_rev` to handle this case, maybe I will try that
this weekend.)

Resolve type variables when checking casting to char

Include compiler-rt in the distribution tarballs

Stop unloading syntax libraries

Externally loaded libraries are able to do things that cause references
to them to survive past the expansion phase (e.g. creating @-box cycles,
launching a task or storing something in task local data). As such, the
library has to stay loaded for the lifetime of the process.

Remove obsolete warnings for `extern mod`

This patch gets rid of ObsoleteExternModAttributesInParens and
ObsoleteNamedExternModule since the replacement of `extern mod` with
`extern crate` avoids those cases and raises different errors. Both have
been around for at least a version which makes this a good moment to get
rid of them.

Replace `extern mod` with `extern crate`

This patch adds a new keyword `crate` which is intended to replace mod
in the context of `extern mod` as part of the issue #9880. The patch
doesn't replace all `extern mod` cases since it is necessary to first
push a new snapshot 0.

The implementation could've been less invasive than this. However I
preferred to take this chance to split the `parse_item_foreign_mod`
method and pull the `extern crate` part out of there, hence the new
method `parse_item_foreign_crate`.

Replace `crate` usage with `krate`

This patch replaces all `crate` usage with `krate` before introducing the
new keyword. This ensures that after introducing the keyword, there
won't be any compilation errors.

krate might not be the most expressive substitution for crate but it's a
very close abbreviation for it. `module` was already used in several
places already.

auto merge of #12210 : zr40/rust/patch-1, r=cmr

According to kimundi on IRC, the current term for `()` is 'unit'. This commit updates tutorial.md to change 'nil' to 'unit' where `()` is described.

auto merge of #12165 : fhahn/rust/change-some-tests, r=alexcrichton

While working on #11363 I stumbled over a couple of ignored tests, that seem to be fixed or invalid.

* src/test/run-pass/issue-3559.rs was fixed in #4726
* src/test/compile-fail/borrowck-call-sendfn.rs was fixed in #2978
* update src/test/compile-fail/issue-5500-1.rs to work with current Rust (I'm not 100% sure if the original condition is tested as mentioned in #5500, but I think so)
* removed src/test/compile-fail/issue-5500.rs because it is tested in
    src/test/run-fail/issue-5500.rs (they are the same test cases, I just renamed src/test/run-fail/addr-of-bot.rs to be consistent with the other issue name

auto merge of #12216 : alexcrichton/rust/another-snap-fix, r=brson

Hurray more snapshot blockers!

Ignore another fourcc test on cross compiles

Reenable some ignored test cases

* src/test/run-pass/issue-3559.rs was fixed in #4726
* src/test/compile-fail/borrowck-call-sendfn.rs was fixed in #2978
* update src/test/compile-fail/issue-5500-1.rs to work with current Rust
* removed src/test/compile-fail/issue-5500.rs because it is tested in
    src/test/run-fail/issue-5500.rs
* src/test/compile-fail/view-items-at-top.rs fixed
* #897 fixed
* compile-fail/issue-6762.rs issue was closed as dup of #6801
* deleted compile-fail/issue-2074.rs because it became irelevant and is
  irrelevant #2074, a test covering this was added in
  4f92f452bd701fb39156d66d4756cc48cc396a8a

Don't hit epoll unless a scheduler absolutely must

Currently, a scheduler will hit epoll() or kqueue() at the end of *every task*.
The reason is that the scheduler will context switch back to the scheduler task,
terminate the previous task, and then return from run_sched_once. In doing so,
the scheduler will poll for any active I/O.

This shows up painfully in benchmarks that have no I/O at all. For example, this
benchmark:

    for _ in range(0, 1000000) {
        spawn(proc() {});
    }

In this benchmark, the scheduler is currently wasting a good chunk of its time
hitting epoll() when there's always active work to be done (run with
RUST_THREADS=1).

This patch uses the previous two commits to alter the scheduler's behavior to
only return from run_sched_once if no work could be found when trying really
really hard. If there is active I/O, this commit will perform the same as
before, falling back to epoll() to check for I/O completion (to not starve I/O
tasks).

In the benchmark above, I got the following numbers:

    12.554s on today's master
    3.861s  with #12172 applied
    2.261s  with both this and #12172 applied

cc #8341

Percolate the (Scheduler, GreenTask) pair upwards

This is in preparation for running do_work in a loop while there are no active
I/O handles. This changes the do_work and interpret_message_queue methods to
return a triple where the last element is a boolean flag as to whether work was
done or not.

This commit preserves the same behavior as before, it simply re-structures the
code in preparation for future work.

Expose whether event loops have active I/O

The green scheduler can optimize its runtime based on this by deciding to not go
to sleep in epoll() if there is no active I/O and there is a task to be stolen.

This is implemented for librustuv by keeping a count of the number of tasks
which are currently homed. If a task is homed, and then performs a blocking I/O
operation, the count will be nonzero while the task is blocked. The homing count
is intentionally 0 when there are I/O handles, but no handles currently blocked.
The reason for this is that epoll() would only be used to wake up the scheduler
anyway.

The crux of this change was to have a `HomingMissile` contain a mutable borrowed
reference back to the `HomeHandle`. The rest of the change was just dealing with
this fallout. This reference is used to decrement the homed handle count in a
HomingMissile's destructor.

Also note that the count maintained is not atomic because all of its
increments/decrements/reads are all on the same I/O thread.

auto merge of #12204 : alexcrichton/rust/seek, r=pcwalton

This adopts the rules posted in #10432:

1. If a seek position is negative, then an error is generated
2. Seeks beyond the end-of-file are allowed. Future writes will fill the gap
   with data and future reads will return errors.
3. Seeks within the bounds of a file are fine.

Closes #10432

auto merge of #12196 : dguenther/rust/fix-fourcc-example, r=alexcrichton

Cleans up a few issues with `fourcc`:
* Corrects the endianness in the docs example
* Removes `#[cfg(not(test))]` (bors might not build this on Windows. If the build fails, I'll re-add it)
* Adds a FIXME referencing the LLVM assert issue we encountered with bors builds on Windows (Same error as #10872)

auto merge of #12180 : eddyb/rust/rm-ty_type, r=nikomatsakis

Removed ty_type (previously used to represent *tydesc).

doc: rename 'nil' to 'unit' when describing `()`

auto merge of #12194 : WebeWizard/rust/master, r=cmr

auto merge of #12190 : alexcrichton/rust/fix-snap-again, r=brson

Loadable syntax extensions don't work when cross compiling (see #12102), so the
fourcc tests all need to be ignored. They're valuable tests, so they shouldn't
be outright ignored, so they're now flagged with ignore-cross-compile

auto merge of #12185 : nikomatsakis/rust/issue-12033-tweak-test, r=alexchrichton

auto merge of #12184 : JeremyLetang/rust/rustpkg-link, r=alexcrichton

Finalize the Seek API

This adopts the rules posted in #10432:

1. If a seek position is negative, then an error is generated
2. Seeks beyond the end-of-file are allowed. Future writes will fill the gap
   with data and future reads will return errors.
3. Seeks within the bounds of a file are fine.

Closes #10432