Fix initial debug statements printing twice

It may mislead you into thinking tasks are spawning twice, when in fact they are
not.
auto merge of #10715 : alexcrichton/rust/fix-log-twice, r=huonw

It may mislead you into thinking tasks are spawning twice, when in fact they are
not.
Removed a few macro-expanding-to-module workarounds

Also documented a few issues
Removed some dead code.

While tracking down how this function became dead, identified a spot
(@fn cannot happen) where we probably would prefer to ICE rather than
pass silently; so added fail! invocation.
auto merge of #10726 : pnkfelix/rust/fsk-remove-at-fn-artifact, r=thestinger

While tracking down how this function became dead, identified a spot
(@fn cannot happen) where we probably would prefer to ICE rather than
pass silently; so added fail! invocation.
libstd: Change `Path::new` to `Path::init`.
auto merge of #10697 : pcwalton/rust/path-new, r=pcwalton

r+

(carrying over from @alexcrichton's review)
Removed useless cmp::{min, max} reexports from the integer modules
Removed module macro workaround for signed and unsigned integers
Implement a lock-free work-stealing deque

This adds an implementation of the Chase-Lev work-stealing deque to libstd
under std::rt::deque. I've been unable to break the implementation of the deque
itself, and it's not super highly optimized just yet (everything uses a SeqCst
memory ordering).

The major snag in implementing the chase-lev deque is that the buffers used to
store data internally cannot get deallocated back to the OS. In the meantime, a
shared buffer pool (synchronized by a normal mutex) is used to
deallocate/allocate buffers from. This is done in hope of not overcommitting too
much memory. It is in theory possible to eventually free the buffers, but one
must be very careful in doing so.

I was unable to get some good numbers from src/test/bench tests (I don't think
many of them are slamming the work queue that much), but I was able to get some
good numbers from one of my own tests. In a recent rewrite of select::select(),
I found that my implementation was incredibly slow due to contention on the
shared work queue. Upon switching to the parallel deque, I saw the contention
drop to 0 and the runtime go from 1.6s to 0.9s with the most amount of time
spent in libuv awakening the schedulers (plus allocations).

Closes #4877
auto merge of #10678 : alexcrichton/rust/issue-4877, r=pcwalton

This adds an implementation of the Chase-Lev work-stealing deque to libstd
under std::rt::deque. I've been unable to break the implementation of the deque
itself, and it's not super highly optimized just yet (everything uses a SeqCst
memory ordering).

The major snag in implementing the chase-lev deque is that the buffers used to
store data internally cannot get deallocated back to the OS. In the meantime, a
shared buffer pool (synchronized by a normal mutex) is used to
deallocate/allocate buffers from. This is done in hope of not overcommitting too
much memory. It is in theory possible to eventually free the buffers, but one
must be very careful in doing so.

I was unable to get some good numbers from src/test/bench tests (I don't think
many of them are slamming the work queue that much), but I was able to get some
good numbers from one of my own tests. In a recent rewrite of select::select(),
I found that my implementation was incredibly slow due to contention on the
shared work queue. Upon switching to the parallel deque, I saw the contention
drop to 0 and the runtime go from 1.6s to 0.9s with the most amount of time
spent in libuv awakening the schedulers (plus allocations).

Closes #4877
auto merge of #10719 : Kimundi/rust/switch_to_multi_item_macros, r=alexcrichton

- Removed module reexport workaround for the integer module macros
- Removed legacy reexports of `cmp::{min, max}` in the integer module macros
- Combined a few macros in `vec` into one
- Documented a few issues