rust/src/libstd/sys, branch 1.0.0

Merge pull request #25299 from alexcrichton/beta-backport

2015-05-11T18:22:01+00:00

Backport mem::forget to beta

Squeeze the last bits of `task`s in documentation in favor of `thread`

2015-05-11T17:05:21+00:00

An automated script was run against the `.rs` and `.md` files, subsituting every occurrence of `task` with `thread`. In the `.rs` files, only the texts in the comment blocks were affected.

std: Mark `mem::forget` as a safe function

2015-05-11T06:16:54+00:00

This commit is an implementation of [RFC 1066][rfc] where the conclusion was that leaking a value is a safe operation in Rust code, so updating the signature of this function follows suit. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md Closes #25186

Add downcasting to std::error::Error

2015-05-05T17:57:01+00:00

This commit brings the `Error` trait in line with the [Error interoperation RFC](https://github.com/rust-lang/rfcs/pull/201) by adding downcasting, which has long been intended. This change means that for any `Error` trait objects that are `'static`, you can downcast to concrete error types. To make this work, it is necessary for `Error` to inherit from `Reflect` (which is currently used to mark concrete types as "permitted for reflection, aka downcasting"). This is a breaking change: it means that impls like ```rust impl Error for MyErrorType { ... } ``` must change to something like ```rust impl Error for MyErrorType { ... } ``` except that `Reflect` is currently unstable (and should remain so for the time being). For now, code can instead bound by `Any`: ```rust impl Error for MyErrorType { ... } ``` which *is* stable and has `Reflect` as a super trait. The downside is that this imposes a `'static` constraint, but that only constrains *when* `Error` is implemented -- it does not actually constrain the types that can implement `Error`. [breaking-change] Conflicts: src/libcore/marker.rs

Test fixes and rebase conflicts

2015-04-30T23:52:54+00:00

std: Fix inheriting standard handles on windows

2015-04-30T22:11:47+00:00

Currently if a standard I/O handle is set to inherited on Windows, no action is taken and the slot in the process information description is set to `INVALID_HANDLE_VALUE`. Due to our passing of `STARTF_USESTDHANDLES`, however, this means that the handle is actually set to nothing and if a child tries to print it will generate an error. This commit fixes this behavior by explicitly creating stdio handles to be placed in these slots by duplicating the current process's I/O handles. This is presumably what previously happened silently by using a file-descriptor-based implementation instead of a `HANDLE`-centric implementation. Along the way this cleans up a lot of code in `Process::spawn` for Windows by ensuring destructors are always run, using more RAII, and limiting the scope of `unsafe` wherever possible.

Remove an unused import on windows

2015-04-25T18:02:56+00:00

Test fixes and rebase conflicts, round 1

2015-04-23T22:18:14+00:00

Conflicts: src/test/run-pass/task-stderr.rs

std: Bring back f32::from_str_radix as an unstable API

2015-04-23T22:18:14+00:00

This API was exercised in a few tests and mirrors the `from_str_radix` functionality of the integer types. Conflicts: src/doc/trpl/traits.md src/libstd/sys/windows/fs2.rs

std: Remove deprecated/unstable num functionality

2015-04-23T22:18:14+00:00

This commit removes all the old casting/generic traits from `std::num` that are no longer in use by the standard library. This additionally removes the old `strconv` module which has not seen much use in quite a long time. All generic functionality has been supplanted with traits in the `num` crate and the `strconv` module is supplanted with the [rust-strconv crate][rust-strconv]. [rust-strconv]: https://github.com/lifthrasiir/rust-strconv This is a breaking change due to the removal of these deprecated crates, and the alternative crates are listed above. [breaking-change] Conflicts: src/libstd/num/strconv.rs