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`.
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.
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
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
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.
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
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.
Consistent parameter name for numeric ‘checked’ operations.
Some checked operations use `rhs` as a parameter name, and some use
`other`. For the sake of consistency, unify everything under the `rhs`
name.
Fixes https://github.com/rust-lang/rust/issues/46308.
Make doc stubs for builtin macros reflect existing support for trailing commas
This modifies the `macro_rules!` stubs in `std` for some of the compiler builtin macros in order to better reflect their currently supported grammar. To my understanding these stubs have no impact on compiler output whatsoever, and only exist so that they may appear in the documentation.
P.S. It is in fact true that `env!` supports trailing commas while `option_env!` currently does not. (I have another issue for this)
I don't imagine there's any way to automatically test these stubs, but I did *informally* test the new definitions on the playpen to see that they accept the desired invocations, as well as inspect the updated doc output.
Some checked operations use `rhs` as a parameter name, and some use
`other`. For the sake of consistency, unify everything under the `rhs`
name.
Fixes https://github.com/rust-lang/rust/issues/46308.
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.
Reject '2' as a binary digit in internals of b: number formatting
The `radix!` macro generates an implementation of the private trait `GenericRadix`, and the code replaced changes Binary's implementation to no longer accept '2' as a valid digit to print.
Granted, this code is literally only ever called from another method in this private trait, and that method has logic to never hand a '2' to the printing function. Even given this, the code's there, I thought it would be best to fix this for clarity of anyone reading it.
impl From<bool> for AtomicBool
This seems like an obvious omission from #45610. ~~I've used the same feature name and version in the hope that this can be backported to beta so it's stabilized with the other impls. If it can't be I'll change it to `1.24.0`.~~
Stabilize some `ascii_ctype` methods
As discussed in #39658, this PR stabilizes those methods for `u8` and `char`. All inherent `ascii_ctype` for `[u8]` and `str` are removed as we prefer the more explicit version `s.chars().all(|c| c.is_ascii_())`.
This PR doesn't modify the `AsciiExt` trait. There, the `ascii_ctype` methods are still unstable. It is planned to remove those in the future (I think). I had to modify some code in `ascii.rs` to properly implement `AsciiExt` for all types.
Fixes#39658.
I don't believe the previous code `0 ... 2` would run into any real problems, but it seems confusing to read, given that '2' is never a valid binary digit.
As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.
Remove `T: Sized` on `ptr::is_null()`
Originally from #44932 -- this is purely a revert of the last commit of that PR, which was removing some changes from the previous commits in the PR. So a revert of a revert means this is code written by @cuviper!
@mikeyhew makes a compelling case in https://github.com/rust-lang/rfcs/issues/433#issuecomment-345495505 for why this is the right way to implement `is_null` for trait objects. And the behavior for slices makes sense to me as well.
```diff
impl<T: ?Sized> *const T {
- pub fn is_null(self) -> bool where T: Sized;
+ pub fn is_null(self) -> bool;
}
impl<T: ?Sized> *mut T {
- pub fn is_null(self) -> bool where T: Sized;
+ pub fn is_null(self) -> bool;
}
