The API documentation is not explicit enough that because `try!` returns
`Err` early for you, you can only use it in functions that return
`Result`. The book mentions this, but if you come across `try!` outside
of the book and look it up in the docs, this restriction on the return
type of the function is not particularly clear.
This adds an example from mem::swap, and provides some suggested uses of this
function.
This is my attempt to summarize the answers to a question I asked on reddit http://www.reddit.com/r/rust/comments/37jcul/what_is_forget_for/ and add the answers to the documentation so that no one else has to google or ask the question again.
This adds an example from mem::swap, and provides some suggested uses of this
function.
Change wording on comment on forget line to be more specific as to why we
need to call forget.
This breaks the examples up into three pieces. The last piece isn't
compiling for some reason.
For slightly complex data structures like `rustc_serialize::json::Json`, it is often convenient to have helper methods like `Json::as_string(&self) -> Option<&str>` that return a borrow of some component of `&self`.
However, when `RefCell`s are involved, keeping a `Ref` around is required to hold a borrow to the insides of a `RefCell`. But `Ref` so far only references the entirety of the contents of a `RefCell`, not a component. But there is no reason it couldn’t: `Ref` internally contains just a data reference and a borrow count reference. The two can be dissociated.
This adds a `map_ref` function that creates a new `Ref` for some other data, but borrowing the same `RefCell` as an existing `Ref`.
Example:
```rust
struct RefCellJson(RefCell<Json>);
impl RefCellJson {
fn as_string(&self) -> Option<Ref<str>> {
map_ref(self.borrow(), |j| j.as_string())
}
}
```
r? @alexcrichton
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement `PartialEq` when `T` does, and just defer to comparing `T` values. There is no reason the same shouldn’t apply to `Eq`.
This enables `#[derive(Eq, PartialEq)]` on e.g. structs that have a `RefCell` field.
r? @alexcrichton
I’m unsure what to do with `#[stable]` attributes on `impl`s. `impl`s generated by `#[derive]` don’t have them.
I'm not sure why `core` is on but it's blocking the playpen. Doesn't seem to be needed but I'm not sure. It's not on the playpen template and playpen works on release and nightly.
Seems easier to understand without `take()`.
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement
`PartialEq` when `T` does, and just defer to comparing `T` values.
There is no reason the same shouldn’t apply to `Eq`.
This enables `#[derive(Eq, PartialEq)]` on e.g.
structs that have a `RefCell` field.
The `debug_builders` feature is up for 1.1 stabilization in #24028. This commit stabilizes the API as-is with no changes.
Some nits that @alexcrichton mentioned that may be worth discussing now if anyone cares:
* Should `debug_tuple_struct` and `DebugTupleStruct` be used instead of `debug_tuple` and `DebugTuple`? It's more typing but is a technically more correct name.
* `DebugStruct` and `DebugTuple` have `field` methods while `DebugSet`, `DebugMap` and `DebugList` have `entry` methods. Should we switch those to something else for consistency?
cc @alexcrichton @aturon
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8\*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
