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
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
`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
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`.
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 25d5a3a194. 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]`.
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!
Found a few 404s that seemed like simple fixes:
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 25d5a3a194. Point at ffi docs instead.
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 commit removes compiler support for the `old_impl_check` attribute which
should in theory be entirely removed now. The last remaining use of it in the
standard library has been updated by moving the type parameter on the
`old_io::Acceptor` trait into an associated type. As a result, this is a
breaking change for all current users of the deprecated `old_io::Acceptor`
trait. Code can be migrated by using the `Connection` associated type instead.
[breaking-change]
Refactored code so that the drop-flag values for initialized
(`DTOR_NEEDED`) versus dropped (`DTOR_DONE`) are given explicit names.
Add `mem::dropped()` (which with `DTOR_DONE == 0` is semantically the
same as `mem::zeroed`, but the point is that it abstracts away from
the particular choice of value for `DTOR_DONE`).
Filling-drop needs to use something other than `ptr::read_and_zero`,
so I added such a function: `ptr::read_and_drop`. But, libraries
should not use it if they can otherwise avoid it.
Fixes to tests to accommodate filling-drop.
This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.
This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.
Main motivation was to update docs for the removal or "demotion" of certain extension traits. The update to the slice docs was larger, since the text was largely outdated.
