| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Just one or two things to finish this module off
|
|
Removed duplicate words
|
|
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]
|
|
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 #22985
Closes #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 #22985
Closes #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]
|
|
cc #23818
|
|
Removed duplicate words
|
|
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 help of https://github.com/lucasdemarchi/codespell
r? @steveklabnik
|
|
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: https://github.com/sfackler/rust-postgres/commit/9cd413d42c287154d6c64cc7913666b0517f35f3.
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
|
|
Fixes #23320
|
|
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]
|
|
All methods are inlined into Iterator with `Self: Sized` bounds to make
sure Iterator is still object safe.
[breaking-change]
This is blocked on ICEs: https://gist.github.com/sfackler/5aff7c57cf8d896e2c6f
Seem to be similar to #23281.
|
|
All methods are inlined into Iterator with `Self: Sized` bounds to make
sure Iterator is still object safe.
[breaking-change]
|
|
Fixes #23320
|
|
Also convert [T]'s Debug impl. The behavior of the alternate flag here's
changing.
|
|
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]
|
|
|
|
|
|
Pretty much what it says on the tin.
|
|
|
|
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
|
|
|
|
Conflicts:
src/test/run-pass/issue-13027.rs
|
|
|
|
`std::dynamic_library` is currently using `std::old_io::Path` specifically. This change brings the API in alignment with `std::fs::File` by having it take `std::path::AsPath`. The Windows code should work, but I admittedly haven't tried it (I don't have a Windows machine readily available right now).
r? @alexcrichton
|
|
Until some backwards-compatibility hazards are fixed in #23121,
these need to be unstable.
[breaking-change]
|
|
Also tweaked a few things.
|
|
Closes #22608
|
|
|
|
Conflicts:
src/libsyntax/feature_gate.rs
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
Conflicts:
src/libcollections/vec.rs
|
|
r? @alexcrichton
|
|
Now that `<[_]>::split` is an inherent method, it will trump `BufRead::split`
when `BufRead` is in scope, so there is no longer a conflict. As a result,
calling `slice.split()` will probably always give you precisely what you want!
|
|
This commit revises `path` and `os_str` to use blanket impls for `From`
on reference types. This both cuts down on the number of required impls,
and means that you can pass through e.g. `T: AsRef<OsStr>` to
`PathBuf::from` without an intermediate call to `as_ref`.
It also makes a FIXME note for later generalizing the blanket impls for
`AsRef` and `AsMut` to use `Deref`/`DerefMut`, once it is possible to do
so.
|
|
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
|
|
|
|
This syntax has been deprecated for quite some time, and there were only a few
remaining uses of it in the codebase anyway.
|
|
Found a few 404s that seemed like simple fixes:
In footer.inc, certain 404 pages were 404ing on the request to jquery.js and playpen.js. This is easily demonstrated by visiting http://doc.rust-lang.org/foo then http://doc.rust-lang.org/foo/bar. The latter 404s, looking for foo/jquery.js.
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
The main page of the API docs referenced c_{str,vec}. Looks like these were deleted in 25d5a3a19423fee01787de87a56d185dd4e0a4e7. Point at ffi docs instead.
|
|
This commit provides a safe, but unstable interface for the `try` functionality
of running a closure and determining whether it panicked or not.
There are two primary reasons that this function was previously marked `unsafe`:
1. A vanilla version of this function exposes the problem of exception safety by
allowing a bare try/catch in the language. It is not clear whether this
concern should be directly tied to `unsafe` in Rust at the API level. At this
time, however, the bounds on `ffi::try` require the closure to be both
`'static` and `Send` (mirroring those of `thread::spawn`). It may be possible
to relax the bounds in the future, but for now it's the level of safety that
we're willing to commit to.
2. Panicking while panicking will leak resources by not running destructors.
Because panicking is still controlled by the standard library, safeguards
remain in place to prevent this from happening.
The new API is now called `catch_panic` and is marked as `#[unstable]` for now.
|
|
Replace zeroing-on-drop with filling-on-drop.
This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future.
Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files).
See further discussion on the internals thread:
http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11
[breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
|
