| Age | Commit message (Collapse) | Author | Lines |
|---|
|
* Update the channel of this release
* Update the bootstrap compiler to the dev artifacts
* Fix compile for last-minute backports
|
|
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.
|
|
Remove transmute in From<&str> impls for Arc/Rc
Performs conversion via raw pointer casts.
|
|
|
|
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
|
|
|
|
Clarify docs for split_at_mut
The `&mut` here didn't make immediate sense to me. Keep the docs for this function consistent with the non-mut version.
|
|
|
|
The `&mut` here didn't make immediate sense to me. Keep the docs for this function consistent with the non-mut version.
|
|
|
|
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.
|
|
Replace option_try macros and match with ? operator
None
|
|
|
|
This reverts commit 00acdbd51decd75ad10815ce7bcf3323830f95d6.
|
|
|
|
|
|
Fix use of rand in liballoc benches
|
|
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.
|
|
Also remove a number of `stage0` annotations and such
|
|
|
|
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 :).
|
|
Check tail node in check_links
|
|
Adding `eprint*!` to the list of macros in the `format!` family
The `eprint!` and `eprintln!` macros were added in 7612727. The `std::fmt` documentation does not mention these macros next to `print!` and `println!` in the [Related macros](https://doc.rust-lang.org/std/fmt/#related-macros) section, and I did not find evidence that this omission was deliberate. This PR adds such documentation.
The first modification is to add `eprint!` and `eprintln!` to the list of related macros in the `format!` family. This is how it appears with this change:
The second modification adds a sub-section for `eprint!` and `eprintln!`. Here is how the new section appears:
|
|
|
|
Relates to rust-lang/rfcs#2140 - drain_filter for all collections
`drain_filter` is implemented instead of `LinkedList::remove_if` based
on review feedback.
|
|
|
|
allocators: don’t assume MIN_ALIGN for small sizes
See individual commit messages.
|
|
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`
|
|
Rollup of 5 pull requests
- Successful merges: #45635, #46177, #46190, #46218, #46220
- Failed merges:
|
|
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 idea of ‘source’ and ‘destination’ aren’t very applicable for this
operation since both slices can both be considered sources and
destinations.
|
|
|
|
|
|
Fix doc tests for trim_right_matches
First pr, but isn't anything big so hopefully it should all be good.
|
|
Fix some docs summary nits
|
|
|
|
|
|
|
|
|
|
See previous commit’s message for what is expected of allocators
in general, and https://github.com/jemalloc/jemalloc/issues/1072
for discussion of what jemalloc does specifically.
|
|
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.
|
|
|
|
|
