When checking for an existing crate, compare against the
`crate_metadata::name` field, which is the crate name which
was requested during resolution, rather than the result of the
`crate_metadata::name()` method, which is the crate name within
the crate metadata, as these may not match when using the --extern
option to `rustc`.

This fixes spurious "multiple crate version" warnings under the
following scenario:

- The crate `foo`, is referenced multiple times
- `--extern foo=./path/to/libbar.rlib` is specified to rustc
- The internal crate name of `libbar.rlib` is not `foo`

The behavior surrounding `Context::should_match_name` and the
comments in `loader.rs` both lead me to believe that this scenario
is intended to work.

Fixes #17186

Package rustc's mingw dependencies into Windows installer to avoid requiring a separate mingw install.

Closes #11782

fixes #17148

gcc, ld, ar, dlltool, windres go into $(RUST)/bin/rustlib/<triple>/bin/
platform libraries and startup objects got into $(RUST)/bin/rustlib/<triple>/lib/

so that rustc can invoke them.

whoops

Fixes https://github.com/rust-lang/rust/pull/16827#issuecomment-55160273

Avoid ever constructing cyclic types in the first place, rather than detecting them in resolve. This simplifies logic elsewhere in the compiler, in particular on the trait reform branch.

r? @pnkfelix or @pcwalton 

cc #5527

Bugs in pdflatex (#12804) are preventing the guide from landing (https://github.com/rust-lang/rust/pull/16657). This solves the immediate problem by changing the build system to prefer lualatex, xelatex to pdflatex (which is apparently obsolete). Because the xelatex on the snapshot bot seems to completely ignore the `-output-directory` option, I also had to frob the makefiles a bit for that case.

The pointer in the slice must not be null, because enum representations
make that assumption. The `exchange_malloc` function returns a non-null
sentinel for the zero size case, and it must not be passed to the
`exchange_free` lang item.

Since the length is always equal to the true capacity, a branch on the
length is enough for most types. Slices of zero size types are
statically special cased to never attempt deallocation. This is the same
implementation as `Vec<T>`.

Closes #14395

Closes #17115

This allows code to access the fields of tuples and tuple structs behind the feature gate `tuple_indexing`:

```rust
#![feature(tuple_indexing)]

let x = (1i, 2i);
assert_eq!(x.1, 2);

struct Point(int, int);
let origin = Point(0, 0);
assert_eq!(origin.0, 0);
assert_eq!(origin.1, 0);
```

Implements [RFC 53](https://github.com/rust-lang/rfcs/blob/master/active/0053-tuple-accessors.md). Closes #16950.

fixes #17148

whoops

Fixes https://github.com/rust-lang/rust/pull/16827#issuecomment-55160273

This builds on https://github.com/rust-lang/rust/pull/17109, putting the target triple into the installer name so that we can have both 32-bit and 64-bit.

The resulting installers will be called `rust-0.12.0-pre-x86_64-w64-mingw32.exe`, etc.

This adds links to SO, reddit, and discuss to the README. The main intent is to start advertising discuss.rust-lang.org more, in a location that doesn't mislead casual users to it (people who are building Rust are more likely to be the right audience than those that are just visiting the web site).

Currently `./configure --llvm-root=...` and similar flags will break incremental builds by forcing reconfiguration on every `make`.  This happens because `reconfig.mk` incorrectly treats submodules in the `-` (uninitialized) state as requiring reconfiguration, and `./configure` deliberately deinitializes unneeded submodules.  The fix is to reconfigure only when submodules are in the `+` state (wrong commit checked out).

Previously, some parts of this optimization were impossible because the
alignment passed to the free function was not correct. That was fully
fixed by #17012.

Closes #17092

Closes #13994

Previously, some parts of this optimization were impossible because the
alignment passed to the free function was not correct. That was fully
fixed by #17012.

Closes #17092

I missed some annotations, and some were in a different style.

Closes #17115

Instead of `extern crate foo = bar`, write `extern crate bar as foo`.
Instead of `extern crate baz = "quux"`, write `extern crate "quux" as
baz`.

Closes #16461.

[breaking-change]

r? @brson

A few steps toward https://github.com/rust-lang/rust/issues/15994

Instead of `extern crate foo = bar`, write `extern crate bar as foo`.
Instead of `extern crate baz = "quux"`, write `extern crate "quux" as
baz`.

Closes #16461.

[breaking-change]

Based on an observation that strings and arguments are always interleaved, thanks to #15832. Additionally optimize invocations where formatting parameters are unspecified for all arguments, e.g. `"{} {:?} {:x}"`, by emptying the `__STATIC_FMTARGS` array. Next, `Arguments::new` replaces an empty slice with `None` so that passing empty `__STATIC_FMTARGS` generates slightly less machine code when `Arguments::new` is inlined. Furthermore, formatting itself treats these cases separately without making redundant copies of formatting parameters.

All in all, this adds a single mov instruction per `write!` in most cases. That's why code size has increased.

I missed some annotations, and some were in a different style.

Avoid ever constructing cyclic types in the first place, rather than detecting them in resolve. This simplifies logic elsewhere in the compiler. cc #5527

This allows code to access the fields of tuples and tuple structs:

    let x = (1i, 2i);
    assert_eq!(x.1, 2);

    struct Point(int, int);
    let origin = Point(0, 0);
    assert_eq!(origin.0, 0);
    assert_eq!(origin.1, 0);