r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
Issue #3869
review? @nikomatsakis
Convert all uses of vec::slice to vec::view Issue #3869
Rename const_view to const_slice
Renamed mut_view to mut_slice
Fix windows build error. `buf` is borrowed by the call to
`as_mut_buf()` and so we must invoke `slice()` outside of that
call.
For Issue #4709:
**c531506 rt: rand.rs expects `rust_next()` to return `uint32_t`, not `size_t`**
rand.rs expects `rustrt::rand_next()` to return `u32`, but the `rand_next()` C function returns `size_t`: ca71c6ec5b/src/libcore/rand.rs (L34)
**f4320b6 move isaac RNG utility functions to new rust_rng.cpp file**
**665e900 encapsulate isaac RNG in `rust_rng` struct**
Move isaac's `randctx` into a `rust_rng` struct to make names similar to `rand::Rng` function names and prepare for auto-reseeding in the next commit.
**9a78dc9 reseed `rust_rng` after generating 32KB**
Precedents from other languages:
* Haskell's `GenAutoReseed` generator reseeds itself after generating 32KB: http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/Crypto-Random-DRBG.html#t:GenAutoReseed
* Go's RNG reseeds itself after generating 1MB: https://code.google.com/p/go/source/browse/src/pkg/crypto/rand/rand_unix.go?name=go1.0.3#94
**9a76d71 don't deplete RNG entropy when there is only one runnable task**
`rust_sched_loop::schedule_task()` unnecessarily calls `isaac_rand()` for the common case when there is only 1 runnable task, thus depleting RNG entropy and incurring unnecessary overhead.
There are no more poor hash functions left in the codebase, and it makes
sense to rely on there being a good hash function thanks to the
inclusion of SipHash and the ease of using it with custom types.
Closes#3041
I removed the unused wrappers methods named `calloc` because they relied on the malloc wrapper having a `bool zero = true` default parameter (which resulted in some accidental zeroing). Perhaps wrapping the actual calloc function would be useful, but I don't know of an existing use case that could use it so I just removed these.
This gives an ~1% performance improvement for TreeMap, which does a lot of small allocations. Vectors use `realloc` which didn't zero before these changes so there's no measurable change in performance.
