| Age | Commit message (Collapse) | Author | Lines |
|
docs(slice): Clarification in binary_search_by
This PR ~fixes a small comment typo~ adds some clarification to a half-open interval in the `binary_search_by` function in `slice`.
|
|
Always `Debug` floats with a decimal point
Fixes #30967
r? @dtolnay
|
|
Stablize RefCell::{replace, swap}
RefCell::replace_with is not stablized in this PR, since it wasn't part of the RFC.
CC #43570
|
|
|
|
Make fmt::DebugList and friends forward formatting parameters
For example, formatting slice of integers with `{:04?}` should zero-pad each integer.
This also affects every use of `#[derive(Debug)]`.
|
|
Move PhantomData<T> from Shared<T> to users of both Shared and #[may_dangle]
After discussing https://github.com/rust-lang/rust/issues/27730#issuecomment-316432083 today with @pnkfelix and @Gankro, we concluded that it’s ok for drop checking not to be much smarter than the current `#[may_dangle]` design which requires an explicit unsafe opt-in.
|
|
|
|
|
|
We can simply use generic intrinsics since cd1848a1a6
Also, minimize unsafe blocks.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
|
|
|
|
|
|
This better illustrates what's happening to the bits behind the scenes.
|
|
|
|
After discussing [1] today with @pnkfelix and @Gankro,
we concluded that it’s ok for drop checking not to be much smarter
than the current `#[may_dangle]` design which requires an explicit
unsafe opt-in.
[1] https://github.com/rust-lang/rust/issues/27730#issuecomment-316432083
|
|
doc: a better example
Closes #46734
|
|
Use a better link for method resolution in Deref docs
rust-lang-nursery/reference#149 breaks these links, so make them point to somewhere which won't break and provides a more deatailed description of method resolution.
cc @Havvy
r? @steveklabnik
|
|
Closes #46734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add `std::fmt::Pointer` implementation for `AtomicPtr`
Resolves #29212.
|
|
Rename never_type_impls gate
We no longer need a separately-named `never_type_impls` gate thanks to https://github.com/rust-lang/rust/issues/43089.
|
|
|
|
Mark ascii methods on primitive types stable in 1.23.0 not 1.21.0.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
|
|
Resolves #29212.
|
|
|
|
|
|
Recommends lazily evaluated alternatives for `Option::or` and `Result::or`
Adds language to docs for `Option` and `Result` recommending the use of lazily evaluated alternatives when appropriate. These comments are intended to echo a [clippy lint] on the same topic. The [reddit discussion] may also be of interest.
[clippy lint]: https://rust-lang-nursery.github.io/rust-clippy/master/index.html#or_fun_call
[reddit discussion]: https://www.reddit.com/r/rust/comments/7hutqn/perils_of_optionor_and_resultor/
|
|
doc: macro `cfg!` evaluating at compile-time
|
|
|
|
|
|
the use of lazily evaluated alternatives when appropriate. These
comments are intended to echo a clippy lint on the same topic (see
https://rust-lang-nursery.github.io/rust-clippy/master/index.html#or_fun_call)
|
|
MIR borrowck: implement union-and-array-compatible semantics
Fixes #44831.
Fixes #44834.
Fixes #45537.
Fixes #45696 (by implementing DerefPure semantics, which is what we want going forward).
r? @nikomatsakis
|
|
Give compile_error macro examples
I cannot get Rust to build at all with it complaining about GCC not being a valid C compiler or something, so letting TravisCI be my tester...
Fixes #46171
|
|
Document behavior of `ptr::swap` with overlapping regions of memory.
Fixes https://github.com/rust-lang/rust/issues/44479.
|
|
Mention the name of ? in Result's docs
Fixes #42725
or at least, this is the best we can really do. #35946 is tracking
better errors already, so that should cover the other part of it.
|
|
|
|
|
|
|
|
I'm not allowed to have the same feature flag associated with multiple stability levels.
|
|
|
|
|
|
RefCell::replace_with is not stablized in this PR, since it wasn't part of the RFC.
|
|
Fixes #42725
or at least, this is the best we can really do. #35946 is tracking
better errors already, so that should cover the other part of it.
|