Convert some push_back users to push
collections: Move push/pop docs to MutableSeq
vim: Add MutableSeq
collections: Make push_back/pop_back default methods
collections: Deprecate shift/unshift

Use insert/remove instead.
Remove kludgy imports from vec! macro
collections: Tweak docs for push
Remove stray llvmdeps.rs
Just land already
auto merge of #15611 : brson/rust/pushpop, r=alexcrichton

This fixes naming conventions for `push`/`pop` from either end of a structure by partially implementing @erickt's suggestion from https://github.com/rust-lang/rust/issues/10852#issuecomment-30823343, namely:

* push/pop from the 'back' are called `push` and `pop`.
* push/pop from the 'front' are called `push_front` and `pop_front`.
* `push`/`pop` are declared on the `MutableSeq` trait.
* Implement `MutableSeq` for `Vec`, `DList`, and `RingBuf`.
* Add `MutableSeq` to the prelude.

I did not make any further refactorings because there is some more extensive thought that needs to be put into the collections traits. This is an easy first step that should close https://github.com/rust-lang/rust/issues/10852.

I left the `push_back` and `pop_back` methods on `DList` and `RingBuf` deprecated. Because `MutableSeq` is in the prelude it shouldn't break many, but it is a breaking change.
auto merge of #15407 : sneves/rust/master, r=aturon

At the moment, writing generic functions for integer types that involve shifting is rather verbose. For example, a function at shifts an integer left by 1 currently requires 

    use std::num::One;
    fn f<T: Int>(x : T) -> T {
        x << One::one()
    }

If the shift amount is not 1, it's even worse:

    use std::num::FromPrimitive;
    fn f<T: Int + FromPrimitive>(x: T) -> T {
        x << FromPrimitive::from_int(2).unwrap()
    }

This patch allows the much simpler implementation

    fn f<T: Int>(x: T) -> T { 
        x << 2
    }

It accomplishes this by changing the built-in integer types (and the `Int` trait) to implement `Shl<uint, T>` instead of `Shl<T, T>` as it currently is defined. Note that the internal implementations of `shl` already cast the right-hand side to `uint`. `BigInt` also implements `Shl<uint, BigInt>`, so this increases consistency.

All of the above applies similarly to right shifts, i.e., `Shr<uint, T>`.
auto merge of #15781 : alexcrichton/rust/issue-15758, r=bblum

Semaphores are not currently designed to handle this case correctly, leading to
very strange behavior. Semaphores as written are intended to count *resources*
and it's not possible to have a negative number of resources.

This alters the behavior and documentation to note that the task will be failed
if the initial count is 0.

Closes #15758
auto merge of #15862 : jakub-/rust/issue-15774, r=alexcrichton

Fixed #15774.
auto merge of #15909 : colemickens/rust/patch-3, r=alexcrichton

Tested this on the playground, the range specifies range(0u, 3), so it should be okay to remove this cast.
Fill in example code for HashMap.

Add an example showing how to use the map with a custom type. Fill in
examples for methods in the hashmap file without ones.

Also move pop_equiv next to related public methods, to not create a
duplicate trait implementation in the docs.
Remove explicit rust code specifier. Unhide use HashMap.
Move contructors to the top of PriorityQueue.
Document PriorityQueue.
auto merge of #15921 : dotdash/rust/match_lifetimes, r=pcwalton

The allocas used in match expression currently don't get good lifetime
markers, in fact they only get lifetime start markers, because their
lifetimes don't match to cleanup scopes.

While the bindings themselves are bog standard and just need a matching
pair of start and end markers, they might need them twice, once for a
guard clause and once for the match body.

The __llmatch alloca OTOH needs a single lifetime start marker, but
when there's a guard clause, it needs two end markers, because its
lifetime ends either when the guard doesn't match or after the match
body.

With these intrinsics in place, LLVM can now, for example, optimize
code like this:

````rust
enum E {
  A1(int),
  A2(int),
  A3(int),
  A4(int),
}

pub fn variants(x: E) {
  match x {
    A1(m) => bar(&m),
    A2(m) => bar(&m),
    A3(m) => bar(&m),
    A4(m) => bar(&m),
  }
}
````

To a single call to bar, using only a single stack slot. It still fails
to eliminate some of checks.

````gas
.Ltmp5:
	.cfi_def_cfa_offset 16
	movb	(%rdi), %al
	testb	%al, %al
	je	.LBB3_5
	movzbl	%al, %eax
	cmpl	$1, %eax
	je	.LBB3_5
	cmpl	$2, %eax
.LBB3_5:
	movq	8(%rdi), %rax
	movq	%rax, (%rsp)
	leaq	(%rsp), %rdi
	callq	_ZN3bar20hcb7a0d8be8e17e37daaE@PLT
	popq	%rax
	retq
````

Refs #15665
Documentation examples for LruCache.