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.
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.
auto merge of #9747 : dim-an/rust/fix-match, r=alexcrichton

When `specialize`ing struct-like enum patterns, compare struct fields to
pattern fields, not pattern fields to pattern fields.

Closes #8351.
pp: add test for raw strs in non-expression positions
Fix merge fallout of privacy changes
auto merge of #9735 : alexcrichton/rust/privacy, r=cmr

This is the culmination and attempted resolution of #8215. The commits have many more details about implementation details and the consequences of this refinement.

I'll point out specific locations which may be possible causes for alarm. In general, I have been very happy with how things have turned out. I'm a little sad that I couldn't remove privacy from resolve as much as I did, but I blame glob imports (although in theory even some of this can be mitigated as well).
auto merge of #9674 : ben0x539/rust/raw-str, r=alexcrichton

This branch parses raw string literals as in #9411.