`Reader`, `Writer`, `MemReader`, `MemWriter`, and `MultiWriter` now work with `Vec<u8>` instead of `~[u8]`. This does introduce some extra copies since `from_utf8_owned` isn't usable anymore, but I think that can't be helped until `~str`'s representation changes.
Deprecates the `shuffle_mut` name in favour of `shuffle` too.
In future there will be many different types of owned
vectors/vector-likes (e.g. DST's ~[], Vec, SmallVec, Rope, ...), and so
privileging just `Vec` with the "functional" `shuffle` method is silly.
The `Float` trait methods will be usable as functions via UFCS, and
we came to a consensus to remove duplicate functions like this a long
time ago.
It does still make sense to keep the duplicate functions when the trait
methods are static, unless the decision to leave out the in-scope trait
name resolution for static methods changes.
move errno -> IoError converter into std, bubble up OSRng errors
Also adds a general errno -> `~str` converter to `std::os`, and makes the failure messages for the things using `OSRng` (e.g. (transitively) the task-local RNG, meaning hashmap initialisation failures aren't such a black box).
The various ...Rng::new() methods can hit IO errors from the OSRng they use,
and it seems sensible to expose them at a higher level. Unfortunately, writing
e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it
failed internally, but this is a problem with all `IoResult`s.
This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).
The `Float` trait methods will be usable as functions via UFCS, and
we came to a consensus to remove duplicate functions like this a long
time ago.
It does still make sense to keep the duplicate functions when the trait
methods are static, unless the decision to leave out the in-scope trait
name resolution for static methods changes.
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
It's possible for a reader to have a short read, and there's no reason the task
should fail in this scenario. By using fill(), this has a stronger guarantee
that the buffer will get filled with data.
The details can be found in the comment I wrote on the block in question, but
the gist of it is that our usage of the TIB for a stack limit was causing
CryptAcquireContext to fail, so we temporarily get around it by setting the
stack limit to 0.
This commit switches over the backtrace infrastructure from piggy-backing off
the RUST_LOG environment variable to using the RUST_BACKTRACE environment
variable (logging is now disabled in libstd).
lint: add lint for use of a `~[T]`.
This is useless at the moment (since pretty much every crate uses
`~[]`), but should help avoid regressions once completely removed from a
crate.
This should be called far less than it is because it does expensive OS
interactions and seeding of the internal RNG, `task_rng` amortises this
cost. The main problem is the name is so short and suggestive.
The direct equivalent is `StdRng::new`, which does precisely the same
thing.
The deprecation will make migrating away from the function easier.
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
