Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
update char_indices example to highlight big chars
There was a comment today in IRC where someone thought `char_indices()` and `chars().enumerate()` were equivalent, so i wanted to put an example in the docs where that wasn't true.
r? @rust-lang/docs
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
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.
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.
Improve documentation for slice swap/copy/clone operations.
Fixes#45636.
- Demonstrate how to use these operations with slices of differing
lengths
- Demonstrate how to swap/copy/clone sub-slices of a slice using
`split_at_mut`
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.
Introduce LinkedList::drain_filter
This introduces `LinkedList::remove_if`.
This operation embodies one of the use-cases where `LinkedList` would typically be preferred over `Vec`: random removal and retrieval.
There are a number of considerations with this:
Should there be two `remove_if` methods? One where elements are only removed, one which returns a collection of removed elements.
Should this be implemented using a draining iterator pattern that covers both cases? I suspect that would incur a bit of overhead (moving the element into the iterator, then into a new collection). But I'm not sure. Maybe that's an acceptable compromise to maximize flexibility.
I don't feel I've had enough exposure to unsafe programming in rust to be certain the implementation is correct. This relies quite heavily on moving around copies of Shared pointers to make the code reasonable. Please help me out :).
Relates to rust-lang/rfcs#2140 - drain_filter for all collections
`drain_filter` is implemented instead of `LinkedList::remove_if` based
on review feedback.
Fixes#45636.
- Demonstrate how to use these operations with slices of differing
lengths
- Demonstrate how to swap/copy/clone sub-slices of a slice using
`split_at_mut`
Rename param in `[T]::swap_with_slice` from `src` to `other`.
The idea of ‘source’ and ‘destination’ aren’t very applicable for this
operation since both slices can both be considered sources and
destinations.
Add Box::leak<'a>(Box<T>) -> &'a mut T where T: 'a
Adds:
```rust
impl<T: ?Sized> Box<T> {
pub fn leak<'a>(b: Box<T>) -> &'a mut T where T: 'a {
unsafe { &mut *Box::into_raw(b) }
}
}
```
which is useful for when you just want to put some stuff on the heap and then have a reference to it for the remainder of the program.
r? @sfackler
cc @durka
The GNU C library (glibc) is documented to always allocate with an alignment
of at least 8 or 16 bytes, on 32-bit or 64-bit platforms:
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
This matches our use of `MIN_ALIGN` before this commit.
However, even when libc is glibc, the program might be linked
with another allocator that redefines the `malloc` symbol and friends.
(The `alloc_jemalloc` crate does, in some cases.)
So `alloc_system` doesn’t know which allocator it calls,
and needs to be conservative in assumptions it makes.
The C standard says:
https://port70.net/%7Ensz/c/c11/n1570.html#7.22.3
> The pointer returned if the allocation succeeds is suitably aligned
> so that it may be assigned to a pointer to any type of object
> with a fundamental alignment requirement
https://port70.net/~nsz/c/c11/n1570.html#6.2.8p2
> A fundamental alignment is represented by an alignment less than
> or equal to the greatest alignment supported by the implementation
> in all contexts, which is equal to `_Alignof (max_align_t)`.
`_Alignof (max_align_t)` depends on the ABI and doesn’t seem to have
a clear definition, but it seems to match our `MIN_ALIGN` in practice.
However, the size of objects is rounded up to the next multiple
of their alignment (since that size is also the stride used in arrays).
Conversely, the alignment of a non-zero-size object is at most its size.
So for example it seems ot be legal for `malloc(8)` to return a pointer
that’s only 8-bytes-aligned, even if `_Alignof (max_align_t)` is 16.
This has been discussed in #39658. It's a bit ambiguous how those
methods work for a sequence of ascii values. We prefer users writing
`s.iter().all(|b| b.is_ascii_...())` explicitly.
The AsciiExt methods still exist and are implemented for `str`
and `[u8]`. We will deprecated or remove those later.
