Add get_opt to std::vec
Use the correct logging crate while monomorphing

This makes sure that the top-level crate name is correct when emitting log
statements for a monomorphized function in another crate. This happens by
tracing the monomorphized ID back to the external source and then using that
crate index to get the name of the crate.

Closes #3046
Document logging and remove old functions

This adds a large doc-block to the top of the std::logging module explaining how
to use it. This is mostly just making sure that all the information in the
manual's section about logging is also here (in case someone decides to look
into this module first).

This also removes the old console_{on,off} methods. As far as I can tell, the
functions were only used by the compiler, and there's no reason for them to be
used because they're all turned off by default anyway (maybe they were turned on
by default at some point...)

I believe that this is the final nail in the coffin and closes #5021
Use slice representation for child crate maps
Use slice representation for module entries in CrateMap

Relaxe lifetime of CrateMap as well.
Use &'self str instead of raw char pointer in ModEntry
Add code for older crate map versions, bumped crate map version number
Implement feature-gating for the compiler

A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.

Closes #9304
Closes #9305
Closes #9306
Closes #9331
rustpkg: Fix fetching remote packages

Closes #9193
Clearer error message for external trait and type

The old error message implied that external traits could never
be implemented locally.
auto merge of #9682 : skade/rust/clearer-error-message-for-external-type-and-trait, r=alexcrichton

The old error message implied that external traits could never
be implemented locally.
get_crate_map returns an Option
auto merge of #9593 : fhahn/rust/logging-unsafe-removal, r=alexcrichton

This pull request changes to memory layout of the `CrateMap` struct to use static slices instead of raw pointers. Most of the discussion took place [here](https://github.com/fhahn/rust/commit/63b5975efa10af7df3df0a50d8d7f9c8d5bcf9e9#L1R92) .

The memory layout of CrateMap changed, without bumping the version number in the struct. Another, more backward compatible, solution would be to keep the old code and increase the version number in the new struct. On the other hand, the `annihilate_fn` pointer was removed without bumping the version number recently.

At the moment, the stage0 compiler does not use the new memory layout, which would lead the segfaults during stage0 compilation, so I've added a dummy `iter_crate_map` function for stage0, which does nothing. Again, this could be avoided if we'd bump the version number in the struct and keep the old code.

I'd like to use a normal `for` loop [here](https://github.com/fhahn/rust/compare/logging-unsafe-removal?expand=1#L1R109), 

        for child in children.iter() {
            do_iter_crate_map(child, |x| f(x), visited);
        }


but for some reason this only yields `error: unresolved enum variant, struct or const 'Some'` and I have no idea why.
auto merge of #9741 : catamorphism/rust/rustpkg-remotes, r=cmr

r? @cmr Closes #9193
Add appropriate #[feature] directives to tests
auto merge of #9703 : alexcrichton/rust/compiler-features, r=cmr

This implements the necessary logic for gating particular features off by default in the compiler. There are a number of issues which have been wanting this form of mechanism, and this initially gates features which we have open issues for.

Additionally, this should unblock #9255
Hide internal stuff in check_match.rs
Add tests for issue 8351
Fix bug in match checking

When `specialize`ing struct-like enum patterns, compare struct fields to
pattern fields, not pattern fields to pattern fields.

Closes #8351.
Extract privacy checking from name resolution

This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:

1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.

"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.

I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.

Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.

The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).

Closes #8215