Document for-loop in tutorial section on loops
 Explain container iteration in the loop tutorial

 As suggested by @pnkfelix in #12161, this extends the examples by a for-loop
 that iterates over a string as an example for container iteration.
Upgrade LLVM for segmented stacks on thumb

This updates the LLVM submodule to the `rust-llvm-2014-02-19` tag which is the
old one with https://github.com/rust-lang/llvm/pull/4 cherry-picked on top.

Awesome job by @neykov for this!
Update comments in the prelude

The comments say that the prelude imports std::io::println since it would
be annoying to have to import it in every program that uses it. However,
the prelude doesn't actually import that function anymore. So, update the
comments to better match reality.
move enum_set to libcollections. #8784
rustc: avoid compiler generated `unsafe` blocks leaking.

Previously an `unsafe` block created by the compiler (like those in the
formatting macros) would be "ignored" if surrounded by `unsafe`, that
is, the internal unsafety would be being legitimised by the external
block:

    unsafe { println!("...") } =(expansion)=> unsafe { ... unsafe { ... } }

And the code in the inner block would be using the outer block, making
it considered used (and the inner one considered unused).

This patch forces the compiler to create a new unsafe context for
compiler generated blocks, so that their internal unsafety doesn't
escape to external blocks.

Fixes #12418.
ptr::RawPtr, spell out units used for the `offset` argument.

spell out units used for the `offset` argument, so that callers do not
try to scale to byte units themselves.
Fix some typos.
Return a buffered stdin by default.

One of the most common ways to use the stdin stream is to read it line by line
for a small program. In order to facilitate this common usage pattern, this
commit changes the stdin() function to return a BufferedReader by default. A new
`stdin_raw()` method was added to get access to the raw unbuffered stream.

I have not changed the stdout or stderr methods because they are currently
unable to flush in their destructor, but #12403 should have just fixed that.
Mass rename if_ok! to try!

This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.

The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.

The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.

Close #12037
auto merge of #12161 : aepsil0n/rust/docs/for-loop, r=alexcrichton

I just started learning Rust and the absence of an explanation of the for-loop in the beginning really bugged me about the tutorial. Hence I simply added these lines, where I would have expected them. I know that there is something later on in the section on traits. However, this simple iteration scheme feels like something that you should be aware of right away.
Register new snapshots

This contains the fix for #4252 so we can start using methods in destructors.
auto merge of #12401 : alexcrichton/rust/if-ok-2-try, r=brson

This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.

The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.

The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.

Close #12037
Re-work loading crates with nicer errors

This commit rewrites crate loading internally in attempt to look at less
metadata and provide nicer errors. The loading is now split up into a few
stages:

1. Collect a mapping of (hash => ~[Path]) for a set of candidate libraries for a
   given search. The hash is the hash in the filename and the Path is the
   location of the library in question. All candidates are filtered based on
   their prefix/suffix (dylib/rlib appropriate) and then the hash/version are
   split up and are compared (if necessary).

   This means that if you're looking for an exact hash of library you don't have
   to open up the metadata of all libraries named the same, but also in your
   path.

2. Once this mapping is constructed, each (hash, ~[Path]) pair is filtered down
   to just a Path. This is necessary because the same rlib could show up twice
   in the path in multiple locations. Right now the filenames are based on just
   the crate id, so this could be indicative of multiple version of a crate
   during one crate_id lifetime in the path. If multiple duplicate crates are
   found, an error is generated.

3. Now that we have a mapping of (hash => Path), we error on multiple versions
   saying that multiple versions were found. Only if there's one (hash => Path)
   pair do we actually return that Path and its metadata.

With this restructuring, it restructures code so errors which were assertions
previously are now first-class errors. Additionally, this should read much less
metadata with lots of crates of the same name or same version in a path.

Closes #11908
configure: Accept LLVM 3.5 for building rust

This is the current head of LLVM, and we can indeed build with 3.5
mk: Fix --llvm-root finding tools

LLVM's tools are not contained in the local directory if --llvm-root is used by
the ./configure script. This fixes the installation path to be the root provided
by --llvm-root.
auto merge of #12164 : alexcrichton/rust/rlibs-and-dylibs, r=cmr

The first commit improves error messages during linking, and the second commit improves error messages during crate-loading time.

Closes #12297
Closes #12377
configure: Accept LLVM 3.5 for building rust

This is the current head of LLVM, and we can indeed build with 3.5
mk: Fix --llvm-root finding tools

LLVM's tools are not contained in the local directory if --llvm-root is used by
the ./configure script. This fixes the installation path to be the root provided
by --llvm-root.
Add a Travis-CI configuration for the repo

Travis CI provides an easy-to-use continuous integration infrastructure for
github repos to use. Travis will automatically test all PRs which are opened
against the rust repository, informing PR owners of the test results.

I believe that this will be a very convenient piece of infrastructure as we'll
be able to reduce the load on bors quite a bit. In theory all PRs opened have
had the full test suite run against them, but unfortunately this is rarely the
case (I'm a prime suspect). Travis will be able to provide easy and relatively
quick (~30min) feedback for PRs. By ensuring fewer failures on bors, we can
hopefully feed more successful jobs to bors.

Overall, I expect this to be very helpful for new contributors as well as
regular contributors as it's another layer of tests being run which will
hopefully catch things sooner. One of the most convenient parts about using
Travis is that there's very little burden in terms of maintenance, and if things
go wrong we can easily turn travis completely off.

Note that this is *not* the metric by which a PR will be merged with. Using
travis will purely be another source for running tests, we will continue to gate
all PRs on bors.