debuginfo: Make names of types in debuginfo reliable and omit source locations from debug info type descriptions.

So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using ppaux::ty_to_str() and brings type names, as they show up in the DWARF information, in line with GCC and Clang:

* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.

Care is also taken to reliably make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.

This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be reenabled for type descriptions.
Fix rotate_{left, right} for multiple of bitsize rotation amounts

Add additional rotation tests
install: Correct libdir for Windows installs.

Platform-detection code from `configure` copied over to `install.sh`
in order to special case the lib dir being `bin` on Windows instead
of `lib`.

Short-term fix for #13810.
auto merge of #15087 : iliekturtles/rust/13810-make-install-mingw32, r=brson

Short-term fix per @brson's comment: https://github.com/rust-lang/rust/issues/13810#issuecomment-43562843. Tested on Win7 x64 and Linux.

One possible issue is that `install.sh` doesn't have a `need_cmd` definition like `configure` does. Should this be ported over as well?

Platform-detection code from `configure` copied over to `install.sh` in
order to special case the lib dir being `bin` on Windows instead of
`lib`.

Short-term fix for #13810.
auto merge of #15324 : sneves/rust/master, r=alexcrichton

The current implementation of `rotate_left` and `rotate_right` are incorrect when the rotation amount is 0, or a multiple of the input's bitsize. When `n = 0`, the expression

    (self >> n) | (self << ($BITS - n))

results in a shift left by `$BITS` bits, which is undefined behavior (see https://github.com/rust-lang/rust/issues/10183), and currently results in a hardcoded `-1` value, instead of the original input value. Reducing `($BITS - n)` modulo `$BITS`, simplified to `(-n % $BITS)`, fixes this problem.
Improve code reuse between trans/_match.rs and check_match.rs

The specialization logic for patterns is really the same in both
exhaustiveness/reachability checking and codegen.
auto merge of #15078 : jakub-/rust/pattern-matching-refactor-vol-2, r=pnkfelix

I believe there's more commonality to be found there but maybe small steps are better. I'm also in the process of documenting what I can, I will see if I can add it to this PR.

It also seems to me that ideally some of this stuff (especially the pattern sanity check) could live as a separate compiler-agnostic module but I understand this may not be the right time (if not the worst) to start the process of modularising rustc.
auto merge of #15199 : michaelwoerister/rust/cross-crate-stability, r=luqmana

So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using `ppaux::ty_to_str()` and brings type names (as they show up in the DWARF information) in line with GCC and Clang:

* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.

Care is also taken to make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.

This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be re-enabled for type descriptions.

`RUSTFLAGS=-g make check` no works again for me locally, including the LTO test cases (note that I've taken care of #15156 by reverting the change in LLVM that @luqmana identified as the culprit for that issue).
rustc: Remove CrateId and all related support

This commit removes all support in the compiler for the #[crate_id] attribute
and all of its derivative infrastructure. A list of the functionality removed is:

* The #[crate_id] attribute no longer exists
* There is no longer the concept of a version of a crate
* Version numbers are no longer appended to symbol names
* The --crate-id command line option has been removed

To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the
crate itself should be mentioned. The version/path of the old crate id should be
removed.

For a transitionary state, the #[crate_id] attribute is still accepted if
the #[crate_name] is not present, but it is warned about if it is the only
identifier present.

RFC: 0035-remove-crate-id
[breaking-change]
rustc: Add a new codegen flag, -C metadata=foo

This metadata is used to drive the hash of all symbols in a crate. The flag can
be specified a multiple number of times

RFC: 0035-remove-crate-id
rustc: Modify crate loading to ignore versions

This commit modifies crate loading to purely work off a `crate_name` and nothing
else. This commit also changes the patterns recognized from `lib<foo>-*` to
`lib<foo>*` to accomodate the future renamings of output files.

RFC: 0035-remove-crate-id
Add #[crate_name] attributes as necessary
rustc: Stop putting hashes in filenames by default

The compiler will no longer insert a hash or version into a filename by default.
Instead, all output is simply based off the crate name being compiled. For
example, a crate name of `foo` would produce the following outputs:

* bin => foo
* rlib => libfoo.rlib
* dylib => libfoo.{so,dylib} or foo.dll
* staticlib => libfoo.a

The old behavior has been moved behind a new codegen flag,
`-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and
a crate name of `foo`, the following outputs would be generated:

* bin => foo (same old behavior)
* rlib => libfoobar.rlib
* dylib => libfoobar.{so,dylib} or foobar.dll
* staticlib => libfoobar.a

The makefiles have been altered to pass a hash by default to invocations of
`rustc` so all installed rust libraries will have a hash in their filename. This
is done because the standard libraries are intended to be installed into
privileged directories such as /usr/local. Additionally, it involves very few
build system changes!

RFC: 0035-remove-crate-id
[breaking-change]
rustc: Add a flag for specifying dependencies

This comit implements a new flag, --extern, which is used to specify where a
crate is located. The purpose of this flag is to bypass the normal crate
loading/matching of the compiler to point it directly at the right file.

This flag takes the form `--extern foo=bar` where `foo` is the name of a crate
and `bar` is the location at which to find the crate. Multiple `--extern`
directives are allowed with the same crate name to specify the rlib/dylib pair
for a crate. It is invalid to specify more than one rlib or more than one dylib,
and it's required that the crates are valid rust crates.

I have also added some extensive documentation to metadata::loader about how
crate loading should work.

RFC: 0035-remove-crate-id
test: Fix tests for crate_id removal

This involved removing some tests whose functionality was removed such as many
of the crateresolve tests
rustc: Repurpose the --crate-name CLI flag

In a cargo-driven world the primary location for the name of a crate will be in
its manifest, not in the source file itself. The purpose of this flag is to
reduce required duplication for new cargo projects.

This is a breaking change because the existing --crate-name flag actually
printed the crate name. This flag was renamed to --print-crate-name, and to
maintain consistence, the --crate-file-name flag was renamed to
--print-file-name.

To maintain backwards compatibility, the --crate-file-name flag is still
recognized, but it is deprecated.

[breaking-change]
Test fixes and rebase conflicts