docs(alloc::fmt): Make type optional, instead of matching empty string
Think this is clearer.
Noticed as I was implementing [`tree-sitter-rust-format-args`](https://github.com/nik-rev/tree-sitter-rust-format-args), and attempting to match the empty string results in an error.
`std::vec`: Add UB check for `set_len`, `from_raw_parts_in`, and etc.
Closesrust-lang/rust#143813
I noticed that `from_parts_in` do the similar things like `from_raw_parts_in`, so I add the UB check in the last commit. If it is not appropriate, I will remove it.
And I fix a typo in the first commit.
r? `@scottmcm`
Fix in std::String docs
This PR removes the word “else” from the sentence ('something else similar') in the String documentation to improve clarity.
Fixesrust-lang/rust#143579.
Make __rust_alloc_error_handler_should_panic a function
Fixesrust-lang/rust#143253
`__rust_alloc_error_handler_should_panic` is a static but was being exported as a function.
For most targets this doesn't matter, but Arm64EC Windows uses different decorations for exported variables vs functions, hence it fails to link when `-Z oom=abort` is enabled.
We've had issues in the past with statics like this (see rust-lang/rust#141061) but the tldr; is that Arm64EC needs symbols correctly exported as either a function or data, and data MUST and MUST ONLY be marked `dllimport` when the symbol is being imported from another binary, which is non-trivial to calculate for these compiler-generated statics.
So, instead, the easiest thing to do is to make `__rust_alloc_error_handler_should_panic` a function instead.
Since `__rust_alloc_error_handler_should_panic` isn't involved in any linking shenanigans, I've marked it as `AlwaysInline` with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.
r? `@bjorn3`
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`)
- rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore)
- rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`)
- rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`)
- rust-lang/rust#142237 (Detect more cases of unused_parens around types)
- rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments)
- rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself)
- rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too)
- rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`)
- rust-lang/rust#143276 (loop match: handle opaque patterns)
- rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
Also applies to `Vec::into_raw_parts`.
The expectation is that you can round-trip these methods with
`from_raw`, but this is only true when using the global allocator. With
custom allocators you should instead be using
`into_raw_with_allocator` and `from_raw_in`.
The implementation of `Box::leak` is changed to use
`Box::into_raw_with_allocator` and explicitly leak the allocator (which
was already the existing behavior). This is because, for `leak` to be
safe, the allocator must not free its underlying backing store. The
`Allocator` trait only guarantees that allocated memory remains valid
until the allocator is dropped.
The method `BTreeSet::from_sorted_iter` was introduced in 49ccb7519f55bd117d2ab50b7a030637f380aec6,
but it was not consistently used throughout the codebase. As a result, some code redundantly reimplemented its logic.
This commit fixes the problem.
Remove incorrect comments in `Weak`
It is currently possible to create a dangling `Weak` to a DST by calling `Weak::new()` for a sized type, then doing an unsized coercion. Therefore, the comments are wrong.
These comments were added in <https://github.com/rust-lang/rust/pull/73845>. As far as I can tell, the guarantee in the comment was only previously used in the `as_ptr` method. However, the current implementation of `as_ptr` no longer relies on this guarantee.
Allow comparisons between `CStr`, `CString`, and `Cow<CStr>`.
Closes: #137265
This PR adds the trait implementations proposed in the [ACP](https://github.com/rust-lang/libs-team/issues/517/) under the `c_string_eq_c_str` feature gate:
```rust
// core::ffi
impl PartialEq<&Self> for CStr;
impl PartialEq<CString> for CStr;
impl PartialEq<Cow<'_, Self>> for CStr;
// alloc::ffi
impl PartialEq<CStr> for CString;
impl PartialEq<&CStr> for CString;
impl PartialEq<Cow<'_, CStr>> for CString;
// alloc::borrow
impl PartialEq<CStr> for Cow<'_, CStr>;
impl PartialEq<&CStr> for Cow<'_, CStr>;
impl PartialEq<CString> for Cow<'_, CStr>;
```
As I understand it, stable traits cannot be unstably implemented for stable types, and we would thereby be forced to skip the FCP and directly stabilise these implementations (as is done in this PR).
(`@joshtriplett` mentioned that Crater may have to be run).
Let String pass #[track_caller] to its Vec calls
I've added `#[track_caller]` to `String` methods that delegate to `Vec` methods that already have `#[track_caller]`.
I've also added `#[track_caller]` to methods that have `assert!` or `panic!` due to invalid inputs.
Convert `ilog(10)` to `ilog10()`
Except in tests, convert `integer.ilog(10)` to `integer.ilog10()` for better speed and to provide better examples of code that efficiently counts decimal digits. I couldn't find any instances of `integer.ilog(2)`.
Use a distinct `ToString` implementation for `u128` and `i128`
Part of https://github.com/rust-lang/rust/issues/135543.
Follow-up of rust-lang/rust#136264.
When working on https://github.com/rust-lang/rust/pull/142098, I realized that `i128` and `u128` could also benefit from a distinct `ToString` implementation so here it.
The last commit is just me realizing that I forgot to add the format tests for `usize` and `isize`.
Here is the bench comparison:
| bench name | last nightly | with this PR | diff |
|-|-|-|-|
| bench_i128 | 29.25 ns/iter (+/- 0.66) | 17.52 ns/iter (+/- 0.7) | -40.1% |
| bench_u128 | 34.06 ns/iter (+/- 0.21) | 16.1 ns/iter (+/- 0.6) | -52.7% |
I used this code to test:
```rust
#![feature(test)]
extern crate test;
use test::{Bencher, black_box};
#[inline(always)]
fn convert_to_string<T: ToString>(n: T) -> String {
n.to_string()
}
macro_rules! decl_benches {
($($name:ident: $ty:ident,)+) => {
$(
#[bench]
fn $name(c: &mut Bencher) {
c.iter(|| convert_to_string(black_box({ let nb: $ty = 20; nb })));
}
)+
}
}
decl_benches! {
bench_u128: u128,
bench_i128: i128,
}
```
It is currently possible to create a dangling `Weak` to a DST by
calling `Weak::new()` for a sized type, then doing an unsized coercion.
Therefore, the comments are wrong.
These comments were added in <https://github.com/rust-lang/rust/pull/73845>.
As far as I can tell, the guarantee in the comment was only previously
used in the `as_ptr` method. However, the current implementation of
`as_ptr` no longer relies on this guarantee.
Change __rust_no_alloc_shim_is_unstable to be a function
This fixes a long sequence of issues:
1. A customer reported that building for Arm64EC was broken: #138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<https://github.com/rust-lang/rust/pull/140176#issuecomment-2872448443>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: #140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433>. At that point, my original change was reverted (#141024) leaving Arm64EC broken yet again.
Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.
Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.
There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.
There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).
Build with this change applied BEFORE #140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>
Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for #128602)
r? `@bjorn3`
cc `@jieyouxu`
