mk: remove -fno-omit-frame-pointer

This is still used for Rust code (`Options.NoFramePointerElim = true`).
Rename CopyableVector to CloneableVector
Rename OwnedCopyableVector to OwnedCloneableVector
Rename ImmutableCopyableVector to ImmutableCloneableVector
Rename CopyableTuple to CloneableTuple
Implement an unused_result lint

I attempted to implement the lint in two steps. My first attempt was a
default-warn lint about *all* unused results. While this attempt did indeed find
many possible bugs, I felt that the false-positive rate was too high to be
turned on by default for all of Rust.

My second attempt was to make unused-result a default-allow lint, but allow
certain types to opt-in to the notion of "you must use this". For example, the
Result type is now flagged with #[must_use]. This lint about "must use" types is
warn by default (it's different from unused-result).

The unused_must_use lint had a 100% hit rate in the compiler, but there's not
that many places that return Result right now. I believe that this lint is a
crucial step towards moving away from conditions for I/O (because all I/O will
return Result by default). I'm worried that this lint is a little too specific
to Result itself, but I believe that the false positive rate for the
unused_result lint is too high to make it useful when turned on by default.
Document vector destructuring with wildcard '..'
Treat unary struct and enum variants as rvalues

Closes #11681
Fix SIMD bit shifts
stop making visit glue for closures and traits
Flag Result as #[must_use] and deal with fallout.
auto merge of #11754 : alexcrichton/rust/unused-result, r=brson

The general consensus is that we want to move away from conditions for I/O, and I propose a two-step plan for doing so:

1. Warn about unused `Result` types. When all of I/O returns `Result`, it will require you inspect the return value for an error *only if* you have a result you want to look at. By default, for things like `write` returning `Result<(), Error>`, these will all go silently ignored. This lint will prevent blind ignorance of these return values, letting you know that there's something you should do about them.

2. Implement a `try!` macro:

```
macro_rules! try( ($e:expr) => (match $e { Ok(e) => e, Err(e) => return Err(e) }) )
```

With these two tools combined, I feel that we get almost all the benefits of conditions. The first step (the lint) is a sanity check that you're not ignoring return values at callsites. The second step is to provide a convenience method of returning early out of a sequence of computations. After thinking about this for awhile, I don't think that we need the so-called "do-notation" in the compiler itself because I think it's just *too* specialized. Additionally, the `try!` macro is super lightweight, easy to understand, and works almost everywhere. As soon as you want to do something more fancy, my answer is "use match".

Basically, with these two tools in action, I would be comfortable removing conditions. What do others think about this strategy?

----

This PR specifically implements the `unused_result` lint. I actually added two lints, `unused_result` and `unused_must_use`, and the first commit has the rationale for why `unused_result` is turned off by default.
Allow empty functional updating of structs

Fixes #8972
auto merge of #11877 : Armavica/rust/doc-pm-vector, r=alexcrichton

This feature already was in the tutorial, but I believe that the tutorial should be a strict subset of the manual.

I also added an example.
use a more efficient vtable representation

[TyDesc, ... methods] -> [destructor, ... methods]
enable fp-elim when debug info is disabled

This can almost be fully disabled, as it no longer breaks retrieving a
backtrace on OS X as verified by @alexcrichton. However, it still
breaks retrieving the values of parameters. This should be fixable in
the future via a proper location list...

Closes #7477
auto merge of #11879 : thestinger/rust/frame-pointer, r=alexcrichton

This is still used for Rust code (`Options.NoFramePointerElim = true`).
Fixes temporary lifetime computation for static items

closes: #11854
auto merge of #11776 : FlaPer87/rust/issue-11681-static-lifetime, r=nikomatsakis

Closes #11681
Closes #11854
auto merge of #11893 : Armavica/rust/copyable-cloneable, r=huonw

I found awkward to have `MutableCloneableVector` and `CloneableIterator` on the one hand, and `CopyableVector` etc. on the other hand.

The concerned traits are:
* `CopyableVector` --> `CloneableVector`
* `OwnedCopyableVector` --> `OwnedCloneableVector`
* `ImmutableCopyableVector` --> `ImmutableCloneableVector`
* `CopyableTuple` --> `CloneableTuple`