Turn `Cow::is_borrowed,is_owned` into associated functions.
This is done because `Cow` implements `Deref`. Therefore, to avoid conflicts with an inner type having a method of the same name, we use an associated method, like `Box::into_raw`.
Tracking issue: #65143
Revert constification of `AsRef for Cow` due to inference failure
Reported issue: rust-lang/rust#147964
Original PR: rust-lang/rust#145279
`const AsRef` tracking issue: rust-lang/rust#143773
Should have additional crater run to verify this fixes the issue.
Add `String::replace_first` and `String::replace_last`
Rebase of #97977 (cc `@WilliamVenner)`
> Convenience methods that use `match_indices` and `replace_range` to efficiently replace a substring in a string without reallocating, if capacity (and the implementation of `Vec::splice`) allows.
The intra-doc link to `str::replacen` is a direct url-based link to `str::replacen` in `std`'s docs to work around #98941. This means that when building only `alloc`'s docs (and not `std`'s), it will be a broken link. There is precedent for this e.g. in [`core::hint::spin_loop`](https://doc.rust-lang.org/nightly/src/core/hint.rs.html#214) which links to `std::thread::yield_now` using a [url-based link](https://github.com/rust-lang/rust/blob/master/library/core/src/hint.rs#L265) and thus is a dead link when only building `core`'s docs.
ACP: https://github.com/rust-lang/libs-team/issues/506
Add `FromIterator` impls for `ascii::Char`s to `String`s
Wanted to `collect` ascii chars into a `String` while working on #141369 , and was surprised these impls don't exist. Seems to me to be simply oversight.
BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too.
cc #110998
Implement `Debug` for `EncodeWide`
Since `std::os::windows::ffi::EncodeWide` was reexported from `std::sys_common::wtf8::EncodeWide`, which has `#![allow(missing_debug_implementations)]` in the parent module, it did not implement `Debug`. When it was moved to `core`, a placeholder impl was added; fill it in.
This becomes insta-stable.
r? libs-api
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
Move more code to `RawVec::finish_grow`
This move a branch and more code into the cold method `finish_grow`, which means that less code is inlined at each `try_reserve` site. Additionally, this reduces the amount of parameters, so they can all be passed by registers.
Currently it is possible to avoid linking the allocator shim when
__rust_no_alloc_shim_is_unstable_v2 is defined when linking rlibs
directly as some build systems need. However this requires liballoc to
be compiled with --cfg no_global_oom_handling, which places huge
restrictions on what functions you can call and makes it impossible to
use libstd. Or alternatively you have to define
__rust_alloc_error_handler and (when using libstd)
__rust_alloc_error_handler_should_panic
using #[rustc_std_internal_symbol]. With this commit you can either use
libstd and define __rust_alloc_error_handler_should_panic or not use
libstd and use #[alloc_error_handler] instead. Both options are still
unstable though.
Eventually the alloc_error_handler may either be removed entirely
(though the PR for that has been stale for years now) or we may start
using weak symbols for it instead. For the latter case this commit is a
prerequisite anyway.
Add repr(align(2)) to RcInner and ArcInner
`Rc` currently assumes that `RcInner` has at least 2-byte alignment, but on AVR, `usize` has 1-byte alignment (this is because the AVR has 1-byte register sizes, so having 2-byte alignment is generally useless), breaking this assumption.
https://github.com/rust-lang/rust/blob/9f32ccf35fb877270bc44a86a126440f04d676d0/library/alloc/src/rc.rs#L3005-L3008
This PR adds `repr(align(2))` to force `RcInner` to always have at least 2-byte alignment.
Note that `ArcInner` doesn't need `repr(align(2))` because atomic types have the alignment same as its size. This PR adds a comment about this.
This move a branch and more code into the cold method `finish_grow`,
which means that less code is inlined at each `try_reserve` site.
Additionally, this reduces the amount of parameters, so they can all be
passed by registers.
Remove most `#[track_caller]` from allocating Vec methods
They cause significant binary size overhead while contributing little value.
closesrust-lang/rust#146963, see that issue for more details.
BTreeMap: Don't leak allocators when initializing nodes
Memory was allocated via `Box::leak` and thence intended to be tracked and deallocated manually, but the allocator was also leaked, not tracked, and never dropped. Now it is dropped immediately.
According to my reading of the `Allocator` trait, if a copy of the allocator remains live, then its allocations must remain live. Since the B-tree has a copy of the allocator that will only be dropped after the nodes, it's safe to not store the allocator in each node (which would be a much more intrusive change).
Fixes: rust-lang/rust#106203
avoid violating `slice::from_raw_parts` safety contract in `Vec::extract_if`
The implementation of the `Vec::extract_if` iterator violates the safety contract adverized by `slice::from_raw_parts` by always constructing a mutable slice for the entire length of the vector even though that span of memory can contain holes from items already drained. The safety contract of `slice::from_raw_parts` requires that all elements must be properly
initialized.
As an example we can look at the following code:
```rust
let mut v = vec![Box::new(0u64), Box::new(1u64)];
for item in v.extract_if(.., |x| **x == 0) {
drop(item);
}
```
In the second iteration a `&mut [Box<u64>]` slice of length 2 will be constructed. The first slot of the slice contains the bitpattern of an already deallocated box, which is invalid.
This fixes the issue by only creating references to valid items and using pointer manipulation for the rest. I have also taken the liberty to remove the big `unsafe` blocks in place of targetted ones with a SAFETY comment. The approach closely mirrors the implementation of `Vec::retain_mut`.
**Note to reviewers:** The diff is easier to follow with whitespace hidden.
bors