Added unit test to prevent similar mistakes from happening again. The
previous method was wrong because it dereferenced a pointer to a void type to
match on the result. No self pointer was needed, and the correct method
signature took the self value by value.

I feel silly that I made this mistake in https://github.com/mozilla/rust/pull/6348

This closes #6548

The change makes it match the standard Load signature.

As discussed on issue #4819. This is a naive implementation, trusting LLVM to do the relevant optimizations. In the future this could be implemented more efficiently, but it's a start.

Closes #2647

This way it's much easier to add lints throughout compilation correctly, and
functions on impls can alter the way lints are emitted. This involved pretty much rewriting how lints are emitted. Beforehand, only items could alter the lint settings, so whenever a lint was added it had to be associated with whatever item id it was coming from. I removed this (possibly questionably) in favor of just specifying a span and a message when adding a lint. When lint checking comes around, it looks at all the lints and sees which node with attributes best encloses it and uses that level of linting. This means that all consumer code doesn't have to deal with what item things came from (especially because functions on impls aren't items). More details of this can be found in the code (and comments).

As a bonus, I managed to greatly simplify emission of lints in resolve.rs about unused imports. Now instead of it manually tracking what the lint level is, it's all moved over into the lint module (as is to be expected).

Achieves ~3x speedup on lint passes for libcore

This way it's much easier to add lints throughout compilation correctly, and
functions on impls can alter the way lints are emitted.

Closes #5127

r? @nikomatsakis Impls can implement either zero or one traits; this has been true
more or less since we removed classes. So I got rid of the comments
saying "we should support multiple traits" and changed the code to
make it clear that we don't. This is just cleanup, and doesn't break
any existing tests.

Impls can implement either zero or one traits; this has been true
more or less since we removed classes. So I got rid of the comments
saying "we should support multiple traits" and changed the code to
make it clear that we don't. This is just cleanup, and doesn't break
any existing tests.

Simpler version of PR #5974 based on new borrowck.

Add BuiltinBounds to closure type: parse and handle subtyping,
but do not integrate with kindck etc (requires a snapshot first)

r? @brson

but do not integrate with kindck etc (requires a snapshot first)

Fix #4334.

This is still enough to prevent cycles (explanation given in the docstring).