This commit stabilizes a few remaining bits of the `io::Error` type:
* The `Error::new` method is now stable. The last `detail` parameter was removed
and the second `desc` parameter was generalized to `E: Into<Box<Error>>` to
allow creating an I/O error from any form of error. Currently there is no form
of downcasting, but this will be added in time.
* An implementation of `From<&str> for Box<Error>` was added to liballoc to
allow construction of errors from raw strings.
* The `Error::raw_os_error` method was stabilized as-is.
* Trait impls for `Clone`, `Eq`, and `PartialEq` were removed from `Error` as it
is not possible to use them with trait objects.
This is a breaking change due to the modification of the `new` method as well as
the removal of the trait implementations for the `Error` type.
[breaking-change]
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Closes#19470
[breaking-change]
* The `io::Seek` trait.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
r? @alexcrichton
This commit is an implementation of [RFC #1011][rfc] which adds an `exit`
function to the standard library for immediately terminating the current process
with a specified exit code.
[rfc]: https://github.com/rust-lang/rfcs/pull/1011Closes#23914
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
r? @alexcrichton
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
[breaking-change]
This commit stabilizes the platform-specific `io` modules, specifically around
the traits having to do with the raw representation of each object on each
platform.
Specifically, the following material was stabilized:
* `AsRaw{Fd,Socket,Handle}`
* `RawFd` (renamed from `Fd`)
* `RawHandle` (renamed from `Handle`)
* `RawSocket` (renamed from `Socket`)
* `AsRaw{Fd,Socket,Handle}` implementations
* `std::os::{unix, windows}::io`
The following material was added as `#[unstable]`:
* `FromRaw{Fd,Socket,Handle}`
* Implementations for various primitives
There are a number of future improvements that are possible to make to this
module, but this should cover a good bit of functionality desired from these
modules for now. Some specific future additions may include:
* `IntoRawXXX` traits to consume the raw representation and cancel the
auto-destructor.
* `Fd`, `Socket`, and `Handle` abstractions that behave like Rust objects and
have nice methods for various syscalls.
At this time though, these are considered backwards-compatible extensions and
will not be stabilized at this time.
This commit is a breaking change due to the addition of `Raw` in from of the
type aliases in each of the platform-specific modules.
[breaking-change]
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
This commit is an implementation of [RFC #1011][rfc] which adds an `exit`
function to the standard library for immediately terminating the current process
with a specified exit code.
[rfc]: https://github.com/rust-lang/rfcs/pull/1011
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
cc #19470
[breaking-change]
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
r? @alexcrichton
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
r? @alexcrichton
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes#22890
[breaking-change]
This removes the FromError trait, since it can now be expressed using
the new convert::Into trait. All implementations of FromError<E> where
changed to From<E>, and `try!` was changed to use From::from instead.
Because this removes FromError, it is a breaking change, but fixing it
simply requires changing the words `FromError` to `From`, and
`from_error` to `from`.
[breaking-change]
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
[breaking-change]
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes#22890
[breaking-change]
with_end_to_cap is enormously expensive now that it's initializing
memory since it involves 64k allocation + memset on every call. This is
most noticable when calling read_to_end on very small readers, where the
new version if **4 orders of magnitude** faster.
BufReader also depended on with_end_to_cap so I've rewritten it in its
original form.
As a bonus, converted the buffered IO struct Debug impls to use the
debug builders.
I first came across this in sfackler/rust-postgres#106 where a user reported a 10x performance regression. A call to read_to_end turned out to be the culprit: 9cd413d42c.
The new version differs from the old in a couple of ways. The buffer size used is now adaptive. It starts at 32 bytes and doubles each time EOF hasn't been reached up to a limit of 64k. In addition, the buffer is only truncated when EOF or an error has been reached, rather than after every call to read as was the case for the old implementation.
I wrote up a benchmark to compare the old version and new version: https://gist.github.com/sfackler/e979711b0ee2f2063462
It tests a couple of different cases: a high bandwidth reader, a low bandwidth reader, and a low bandwidth reader that won't return more than 10k per call to `read`. The high bandwidth reader should be analagous to use cases when reading from e.g. a `BufReader` or `Vec`, and the low bandwidth readers should be analogous to reading from something like a `TcpStream`.
Of special note, reads from a high bandwith reader containing 4 bytes are now *4,495 times faster*.
```
~/foo ❯ cargo bench
Compiling foo v0.0.1 (file:///home/sfackler/foo)
Running target/release/foo-7498d7dd7faecf5c
running 13 tests
test test_new ... ignored
test new_delay_4 ... bench: 230768 ns/iter (+/- 14812)
test new_delay_4_cap ... bench: 231421 ns/iter (+/- 7211)
test new_delay_5m ... bench: 14495370 ns/iter (+/- 4008648)
test new_delay_5m_cap ... bench: 73127954 ns/iter (+/- 59908587)
test new_nodelay_4 ... bench: 83 ns/iter (+/- 2)
test new_nodelay_5m ... bench: 12527237 ns/iter (+/- 335243)
test std_delay_4 ... bench: 373095 ns/iter (+/- 12613)
test std_delay_4_cap ... bench: 374190 ns/iter (+/- 19611)
test std_delay_5m ... bench: 17356012 ns/iter (+/- 15906588)
test std_delay_5m_cap ... bench: 883555035 ns/iter (+/- 205559857)
test std_nodelay_4 ... bench: 144937 ns/iter (+/- 2448)
test std_nodelay_5m ... bench: 16095893 ns/iter (+/- 3315116)
test result: ok. 0 passed; 0 failed; 1 ignored; 12 measured
```
r? @alexcrichton
with_end_to_cap is enormously expensive now that it's initializing
memory since it involves 64k allocation + memset on every call. This is
most noticable when calling read_to_end on very small readers, where the
new version if **4 orders of magnitude** faster.
BufReader also depended on with_end_to_cap so I've rewritten it in its
original form.
As a bonus, converted the buffered IO struct Debug impls to use the
debug builders.
Fixes#23815
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
Previously a panic was generated for recursive prints due to a double-borrow of
a `RefCell`. This was solved by the second borrow's output being directed
towards the global stdout instead of the per-thread stdout (still experimental
functionality).
After this functionality was altered, however, recursive prints still deadlocked
due to the overridden `write_fmt` method which locked itself first and then
wrote all the data. This was fixed by removing the override of the `write_fmt`
method. This means that unlocked usage of `write!` on a `Stdout`/`Stderr` may be
slower due to acquiring more locks, but it's easy to make more performant with a
call to `.lock()`.
Closes#23781
