Two changes:

1. Make type parameters move by default, even if they have a Copy bound. After all, they could be bound to `~T` or `~[]`. Also, this is a necessary step towards removing `copy` keyword and replacing with clone.

2. Make it illegal to move from `*T`. This is dangerous in a "moves-by-default" scenario, because it's very easy to move when working with a `*T` pointer. Also, it requires zeroing memory, which we hope to do away with someday.

since it creates moves that were not apparent. It also turns out to be not
widely used.

Consider: T:Copy could be bound to ~T, which is not implicitly copyable.

It is suffering from a bad case of megabitrot. #5247

My latest terminfo work introduced a bug in the handling of %i, which was noticed by @huonw after the PR was already merged in.

r? @thestinger

The free glue shouldn't be called for structs, and the drop glue already
contains the destructor.

It can sometimes be useful to have maps/sets of floating point values.

Doing arithmetic with floats and then using them as keys is, of course, not a good idea.

Removes one alloca and store from the drop glue of @ boxes. This speeds
up the rustc build by 1s (might be noise, though).

This allows mass-initialization of large structs without having to specify all the fields.

I'm a bit hesitant, but I wanted to get this out there. I don't really like using the `Zero` trait, because it doesn't really make sense for a type like `HashMap` to use `Zero` as the 'blank allocation' trait. In theory there'd be a new trait, but then that's adding cruft to the language which may not necessarily need to be there.

I do think that this can be useful, but I only implemented `Zero` on the basic types where I thought it made sense, so it may not be all that usable yet. (opinions?)

This is to make sure we track optimizing `vec::from_elem`.

Moves all the remaining functions that could reasonably be methods to be methods, except for some FFI ones (which I believe @erickt is working on, possibly) and `each_split_within`, since I'm not really sure the details of it (I believe @kimundi wrote the current implementation, so maybe he could convert it to an external iterator method on `StrSlice`, e.g. `word_wrap_iter(&self) -> WordWrapIterator<'self>`, where `WordWrapIterator` impls `Iterator<&'self str>`. It probably won't be too hard, since it's already a state machine.)

This also cleans up the comparison impls for the string types, except I'm not sure how the lang items `eq_str` and `eq_str_uniq` need to be handled, so they (`eq_slice` and `eq`) remain stand-alone functions.

r?  (yes, the review request is back, now that I got it building against incom... I mean master!)

(Attempting to port from orphaned pull-request #6764 )

Fix for #3961. Also includes a test case to illustrate the issues. (All of the entries that say "should align" should align with each other, and the four lines near the end that say "compare _" for _ in {A,B,C,D} should line up with each other.)

Before applying this change set:
-- the "(should align)"'s are all over the place, and the form/line feeding spaces are not cut out as one might or might not expect.
-- compare B and D do not match A and C.

(To be honest, its hard to really say what the right behavior is here, and people who are expecting a particular behavior out of a pretty printer in these cases may well get burned.)

replaced with OrdIterator

This moves them all into the traits submodule, and delegates Ord
to the TotalOrd instance. It also deletes the stand-alone lt, gt,
ge and le functions.

The first two become map_chars and lev_distance. Also, remove a few
allocations in rustdoc.

This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

It is suffering from a bad case of megabitrot.

This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

This removes all of the explicit `@mut` fields from `CrateContext`. There are still a few that are managed, but no longer do we have `@mut bool` in the structure.

Most of the changes are changing `@CrateContext` to `@mut CrateContext`, though I did change as many as I could get away with to `&CrateContext` and `&mut CrateContext`. The biggest thing preventing me from changing to `&[mut]` in most places was the instruction counter thing. In two cases, where I got a static borrow error and a dynamic borrow error, I opted to remove the count call there as it was literally the only thing preventing me from switching to `&mut CrateContext` parameters in both cases.

Other things to note:

* the EncoderContext uses borrowed pointers with lifetimes, since it can, though that required me to work around the limitation of not being able to move a structure with borrowed pointers into a heap closure. I changed as much as I could to stack closures, but unfortunately I hit the AST visitor and changing that is somewhat outside the scope of this PR. Instead (and there is a comment to this effect) I choose to unsafely get the structure into the heap, this is because I know the lifetimes involved are safe, even though the compiler can't prove it.

* Many of the changes are workarounds because of the borrow checker, either dynamically freezing it for too long, or inferring too large a scope. This is mostly just from nested function calls where each borrow is considered to last for the entire statement. Other cases are where `CrateContext` was borrowed in a `match` causing it to be borrowed for the entire length of the match, even though that wasn't wanted (or needed).

* I haven't yet tested to see if this changes compilation times in any way. I doubt there will be much of an impact however, as the only major improvements are less indirection and fewer refcount bumps.

* This lays the foundations to remove many more heap allocations in trans as many cases can be changed to use lifetimes instead.

=====

This change includes some other, minor refactorings, as I am planning a series, however I don't want to submit them all at once as it will be hell to continually rebase.