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
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
Fix existing privacy/visibility violations

This commit fixes all of the fallout of the previous commit which is an attempt
to refine privacy. There were a few unfortunate leaks which now must be plugged,
and the most horrible one is the current `shouldnt_be_public` module now inside
`std::rt`. I think that this either needs a slight reorganization of the
runtime, or otherwise it needs to just wait for the external users of these
modules to get replaced with their `rt` implementations.

Other fixes involve making things pub which should be pub, and otherwise
updating error messages that now reference privacy instead of referencing an
"unresolved name" (yay!).
Document visibility in the manual/tutorial

This removes the warning "Note" about visibility not being fully defined, as it
should now be considered fully defined with further bugs being considered just
bugs in the implementation.
rm special case for ty_struct from take glue

This is incorrect, as take glue isn't used for moves.
stop zeroing the drop flag in drop glue

this is only going to cover up real bugs, as it's not part of the model
used to prevent multiple destructor calls
pp: print spaces around '=' in 'extern mod blah = "blah"'
lex raw string literals, like r#"blah"#

Raw string literals are lexed into regular string literals. This is okay
for them to "work" and be usable/testable, but the pretty-printer does
not know about them yet and will just emit regular string literals.
document raw string literals in tutorial.md and rust.md
add vim syntax highlighting support for raw string literals
add token::LIT_STR_RAW(ident, num of # symbols)

Treat it as a synonym for LIT_STR for now.
auto merge of #9751 : thestinger/rust/immediate, r=alexcrichton

This is incorrect, as take glue isn't used for moves.
syntax: Display spans for open delimiters when a file ends prematurely

It's more helpful to list the span of each open delimiter seen so far
than to print out an error with the span of the last position in the file.

Closes #2354
syntax: Remove unnecessary @
add new enum ast::StrStyle as field to ast::lit_str

For the benefit of the pretty printer we want to keep track of how
string literals in the ast were originally represented in the source
code.

This commit changes parser functions so they don't extract strings from
the token stream without at least also returning what style of string
literal it was. This is stored in the resulting ast node for string
literals, obviously, for the package id in `extern mod = r"package id"`
view items, for the inline asm in `asm!()` invocations.

For `asm!()`'s other arguments or for `extern "Rust" fn()` items, I just
the style of string, because it seemed disproportionally cumbersome to
thread that information through the string processing that happens with
those string literals, given the limited advantage raw string literals
would provide in these positions.

The other syntax extensions don't seem to store passed string literals
in the ast, so they also discard the style of strings they parse.