rustc/metadata: Removed stray debug statements
float_to_str_bytes_common can now handle exponential notation
Add LowerExp 'e' and UpperExp 'E' format traits/specifiers
Add some tests for the exponential notation
Remove the initial and trailing blank doc-comment lines
remove old rc extension from detection files
libc: switch `free` to the proper signature

This does not attempt to fully propagate the mutability everywhere, but
gives new code a hint to avoid the same issues.
vec: make unsafe indexing functions higher-level
add new vector representation as a library
hashmap: port to Vec<T>
auto merge of #11294 : alexcrichton/rust/native-timer, r=brson

Commit messages have the fun details

Closes #10925
auto merge of #11611 : SiegeLord/rust/exp_printing, r=alexcrichton

Fixes #6593

Currently, Rust provides no way to print very large or very small floating point values which come up routinely in scientific and modeling work. The classical solution to this is to use the scientific/exponential notation, which not-coincidentally, corresponds to how floating point values are encoded in memory. Given this, there are two solutions to the problem. One is what, as far as I understand it, Python does. I.e. for floating point numbers in a certain range it does what we do today with the `'f'` formatting flag, otherwise it switches to exponential notation. The other way is to provide a set of formatting flags to explicitly choose the exponential notation, like it is done in C. I've chosen the second way as I think its important to provide that kind of control to the user.

This pull request changes the `std::num::strconv::float_to_str_common` function to optionally format floating point numbers using the exponential (scientific) notation. The base of the significant can be varied between 2 and 25, while the base of the exponent can be 2 or 10.

Additionally this adds two new formatting specifiers to `format!` and friends: `'e'` and `'E'` which switch between outputs like `1.0e5` and `1.0E5`. Mostly parroting C stdlib in this sense, although I wasn't going for an exact output match.
auto merge of #11682 : thestinger/rust/vector, r=brson

This is just an initial implementation and does not yet fully replace `~[T]`. A generic initialization syntax for containers is missing, and the slice functionality needs to be reworked to make auto-slicing unnecessary.

Traits for supporting indexing properly are also required. This also needs to be fixed to make ring buffers as easy to use as vectors.

The tests and documentation for `~[T]` can be ported over to this type when it is removed. I don't really expect DST to happen for vectors as having both `~[T]` and `Vec<T>` is overcomplicated and changing the slice representation to 3 words is not at all appealing. Unlike with traits, it's possible (and easy) to implement `RcSlice<T>` and `GcSlice<T>` without compiler help.
auto merge of #11701 : FeGs/rust/stray-debug-in-metadata, r=alexcrichton

When there is `println!` macro in the code, compiling is never end.

```rust
// print.rs
fn main() {
  println!("Hello!");
}
```

```bash
$ RUST_LOG=rustc rustc print.rs
```

And this is a part of output from stderr.

```bash
# ...
Looking up syntax::ast::DefId{crate: 1u32, node: 176234u32}
looking up syntax::ast::DefId{crate: 1u32, node: 176235u32} : extra::ebml::Doc<>{data: &[168u8, 16u8, 0u8, 0u8, 16u8, 51u8, 101u8, 53u8, 97u8, 101u8, 98u8, 56u8, 51u8, 55u8, 97u8, 101u8, 49u8, 54u8, 50u8
# ...
# vector which has infinite length.
```

* note : rust 0.9, 0.10-pre
auto merge of #11737 : alexcrichton/rust/issue-11729, r=thestinger

Closes #11729
auto merge of #11739 : thestinger/rust/rm-old-ext, r=alexcrichton
Add an AtomicU64 type to std::sync::atomics

This also generalizes all atomic intrinsics over T so we'll be able to add u8
atomics if we really feel the need to (do we really want to?)
Enable the +v7 feature on Android by default

With the recently added double word CAS functionality on 32-bit ARM (enabled via
a 64-bit atomic instruction in LLVM IR), without some extra features enabled
LLVM lowers code to function calls which emulate atomic instructions. With the
v7 feature enabled, proper 64-bit CAS instructions are used on 32-bit arm.

I've been told that v7 for arm is what we should have been doing anyway. This is
overridable by providing some other non-empty feature string.
extra: Make room for more sync primitives
extra: Add an intrusive MPSC to be used soon