This moves chars() and lines() out of Buffer and into separate traits (CharsBuffer and LinesBuffer respectively) - this matches the pattern used for bytes() on Reader (with BytesReader).
(I came across this when I wanted a trait object of a Buffer, so that I could use read_line(); rustc errors about std::io::Buffer not being object-safe.)
[breaking-change]
Any uses of Buffer::lines() will need to use the new trait std::io::LinesBuffer.
The same is true for Buffer::chars() with std::io::CharsBuffer.
This test was somewhat sketchy already with a `loop` around `write`, so this
just adds some explicit synchronization to only call `write` once and guarantee
that the error happens.
Closes#18900
This commit slightly tweaks the counting of impl blocks and structs for
the stability summary (so that the block itself isn't counted for
inherent impls, and the fields aren't counted for structs).
A recent change turned off inheritance for the #[stable] by default, but
failed to catch all the cases where this was being used in std. This
patch fixes that problem.
I found some occurrences of "failure" and "fails" in the documentation. I changed them to "panics" if it means a task panic. Otherwise I left it as is, or changed it to "errors" to clearly distinguish them.
Also, I made a minor fix that is breaking the layout of a module page. "Example" is shown in an irrelevant place from the following page: http://doc.rust-lang.org/std/os/index.html
This was a simple case of substitutions being applied inconsistently. I haven't investigated why type parameters are actually showing up in the closure type here, but trans needs to handle them correctly in any case.
The examples in the documentation for syntax::ext::deriving::encodable
are outdated, and do not work. To fix this, the following changes are
applied:
- emit_field() -> emit_struct_field()
- read_field() -> read_struct_field()
- Use Result to report errors
- Add the mut keyword to Encoder/Decoder
- Prefer Encodable::encode() to emit_uint
It seems odd that the `AsRefReader`/`AsRefWriter` have the single method `by_ref()`. This creates the new traits `ByRefReader`/`ByRefWriter` and deprecates the old traits.
The previous implementation was very likely to cause panics during
unwinding through this process:
- child panics, drops its receiver
- taskpool comes back around and sends another job over to that child
- the child receiver has hung up, so the taskpool panics on send
- during unwinding, the taskpool attempts to send a quit message to
the child, causing a panic during unwinding
- panic during unwinding causes a process abort
This meant that TaskPool upgraded any child panic to a full process
abort. This came up in Iron when it caused crashes in long-running
servers.
This implementation uses a single channel to communicate between
spawned tasks and the TaskPool, which significantly reduces the complexity
of the implementation and cuts down on allocation. The TaskPool uses
the channel as a single-producer-multiple-consumer queue.
Additionally, through the use of send_opt and recv_opt instead of
send and recv, this TaskPool is robust on the face of child panics,
both before, during, and after the TaskPool itself is dropped.
Due to the TaskPool no longer using an `init_fn_factory`, this is a
[breaking-change]
otherwise, the API has not changed.
If you used `init_fn_factory` in your code, and this change breaks for
you, you can instead use an `AtomicUint` counter and a channel to
move information into child tasks.
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:
1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.
2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.
Fixes#17484
