The latest versions of `memchr` experience LTO-related issues when
compiling for windows-gnu [1], so needs to be pinned. The issue is
present in the standard library.
`memchr` has been pinned in `rustc_ast`, but since the workspace was
recently split, this pin no longer has any effect on library crates.
Resolve this by adding `memchr` as an _unused_ dependency in `std`,
pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow
non-library crates to upgrade to the latest version.
Link: https://github.com/rust-lang/rust/issues/127890 [1]
Mark `make_ascii_uppercase` and `make_ascii_lowercase` in `[u8]` and `str` as const.
Relevant tracking issue: #130698
This PR extends #130697 and #130713 to the similar methods in byte slices (`[u8]`) and string slices (`str`).
For the `str` methods, this simply requires adding the `const` specifier to the function signatures. The `[u8]` methods, however, require (at least a temporary) reimplementation due to the use of iterators and `for` loops.
Add test for `available_parallelism()`
This is a redo of [this PR](https://github.com/rust-lang/rust/pull/104095).
I changed the location of the test as per comments in the original thread. Otherwise the test is practically the same.
try-job: test-various
Mark `u8::make_ascii_uppercase` and `u8::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
This PR extends #130697 by also marking the `make_ascii_uppercase` and `make_ascii_lowercase` methods in `u8` as const.
The `const_char_make_ascii` feature gate is additionally renamed to `const_make_ascii`.
Support `char::encode_utf16` in const scenarios.
Relevant tracking issue: #130660
The method `char::encode_utf16` should be marked "const" to allow compile-time conversions.
This PR additionally rewrites the `encode_utf16_raw` function for better readability whilst also reducing the amount of unsafe code.
try-job: x86_64-msvc
Add str.as_str() for easy Deref to string slices
Working with `Box<str>` is cumbersome, because in places like `iter.filter()` it can end up being `&Box<str>` or even `&&Box<str>`, and such type doesn't always get auto-dereferenced as expected.
Dereferencing such box to `&str` requires ugly syntax like `&**boxed_str` or `&***boxed_str`, with the exact amount of `*`s.
`Box<str>` is [not easily comparable with other string types](https://github.com/rust-lang/rust/pull/129852) via `PartialEq`. `Box<str>` won't work for lookups in types like `HashSet<String>`, because `Borrow<String>` won't take types like `&Box<str>`. OTOH `set.contains(s.as_str())` works nicely regardless of levels of indirection.
`String` has a simple solution for this: the `as_str()` method, and `Box<str>` should too.
Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const."
With the stabilisation of [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349/), this simply requires adding the `const` specifier to the function signatures.
ABI compatibility: mention Result guarantee
This has been already documented in https://doc.rust-lang.org/std/result/index.html#representation, but for `Option` we mirrored those docs in the "ABI compatibility" section, so let's do the same here.
Cc ``@workingjubilee`` ``@rust-lang/lang``
Avoid re-validating UTF-8 in `FromUtf8Error::into_utf8_lossy`
Part of the unstable feature `string_from_utf8_lossy_owned` - #129436
Refactor `FromUtf8Error::into_utf8_lossy` to copy valid UTF-8 bytes into the buffer, avoiding double validation of bytes.
Add tests that mirror the `String::from_utf8_lossy` tests.
Refactor `into_utf8_lossy` to copy valid UTF-8 bytes into the buffer,
avoiding double validation of bytes.
Add tests that mirror the `String::from_utf8_lossy` tests
Address diagnostics regression for `const_char_encode_utf8`.
Relevant tracking issue: #130512
This PR regains full diagnostics for non-const calls to `char::encode_utf8`.
Remove macOS 10.10 dynamic linker bug workaround
Rust's current minimum macOS version is 10.12, so the hack can be removed. This PR also updates the `remove_dir_all` docs to reflect that all supported macOS versions are protected against TOCTOU race conditions (the fallback implementation was already removed in #127683).
try-job: dist-x86_64-apple
try-job: dist-aarch64-apple
try-job: dist-apple-various
try-job: aarch64-apple
try-job: x86_64-apple-1
`pal::unsupported::process::ExitCode`: use an `u8` instead of a `bool`
`ExitCode` should “represents the status code the current process can return to its parent under normal termination”, but is currently represented as a `bool` on unsupported platforms, making the `impl From<u8> for ExitCode` lossy.
Fixes#130532.
History: [IRLO thread](https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426) (`ExitCode` as a `main` return), #48618 (initial impl), #93445 (`From<u8>` impl).
[Clippy] Get rid of most `std` `match_def_path` usage, swap to diagnostic items.
Part of https://github.com/rust-lang/rust-clippy/issues/5393.
This was going to remove all `std` paths, but `SeekFrom` has issues being cleanly replaced with a diagnostic item as the paths are for variants, which currently cannot be diagnostic items.
This also, as a last step, categories the paths to help with future path removals.
Improve documentation for <integer>::from_str_radix
Two improvements to the documentation:
- Document `-` as a valid character for signed integer destinations
- Make the documentation even more clear that extra whitespace and non-digit characters is invalid. Many other languages, e.g. c++, are very permissive in string to integer routines and simply try to consume as much as they can, ignoring the rest. This is trying to make the transition for developers who are used to the conversion semantics in these languages a bit easier.
Update the minimum external LLVM to 18
With this change, we'll have stable support for LLVM 18 and 19.
For reference, the previous increase to LLVM 17 was #122649.
cc `@rust-lang/wg-llvm`
r? nikic
Win: Open dir for sync access in remove_dir_all
A small follow up to #129800.
We should explicitly open directories for synchronous access. We ultimately use `GetFileInformationByHandleEx` to read directories which should paper over any issues caused by using async directory reads (or else return an error) but it's better to do the right thing in the first place. Note though that `delete` does not read or write any data so it's not necessary there.
Pass `fmt::Arguments` by reference to `PanicInfo` and `PanicMessage`
Resolves#129330
For some reason after #115974 and #126732 optimizations applied to panic handler became worse and compiler stopped removing panic locations if they are not used in the panic message. This PR fixes that and maybe we can merge it into beta before rust 1.81 is released.
Note: optimization only works with `lto = "fat"`.
r? libs-api
Take more advantage of the `isize::MAX` limit in `Layout`
Things like `padding_needed_for` are current implemented being super careful to handle things like `Layout::size` potentially being `usize::MAX`.
But now that #95295 has happened, that's no longer a concern. It's possible to add two `Layout::size`s together without risking overflow now.
So take advantage of that to remove a bunch of checked math that's not actually needed. For example, the round-up-and-add-next-size in `extend` doesn't need any overflow checks at all, just the final check for compatibility with the alignment.
(And while I was doing that I made it all unstably const, because there's nothing in `Layout` that's fundamentally runtime-only.)
Things like `padding_needed_for` are current implemented being super careful to handle things like `Layout::size` potentially being `usize::MAX`.
But now that 95295 has happened, that's no longer a concern. It's possible to add two `Layout::size`s together without risking overflow now.
So take advantage of that to remove a bunch of checked math that's not actually needed. For example, the round-up-and-add-next-size in `extend` doesn't need any overflow checks at all, just the final check for compatibility with the alignment.
(And while I was doing that I made it all unstably const, because there's nothing in `Layout` that's fundamentally runtime-only.)
Remove uneeded PartialOrd bound in cmp::Ord::clamp
There is a `Self: PartialOrd` bound in `Ord::clamp`, but it is already required by the trait itself. Likely a left-over from the const trait deletion in 76dbe29104.
Reported-by: `@noeensarguet`
There is a Self: PartialOrd bound in Ord::clamp, but it is already
required by the trait itself. Likely a left-over from the const trait
deletion in 76dbe29104.
Reported-by: @noeensarguet
Add new_cyclic_in for Rc and Arc
Currently, new_cyclic_in does not exist for Rc and Arc. This is an oversight according to https://github.com/rust-lang/wg-allocators/issues/132.
This PR adds new_cyclic_in for Rc and Arc. The implementation is almost the exact same as new_cyclic with some small differences to make it allocator-specific. new_cyclic's implementation has been replaced with a call to `new_cyclic_in(data_fn, Global)`.
Remaining questions:
* ~~Is requiring Allocator to be Clone OK? According to https://github.com/rust-lang/wg-allocators/issues/88, Allocators should be cheap to clone. I'm just hesitant to add unnecessary constraints, though I don't see an obvious workaround for this function since many called functions in new_cyclic_in expect an owned Allocator. I see Allocator.by_ref() as an option, but that doesn't work on when creating Weak { ptr: init_ptr, alloc: alloc.clone() }, because the type of Weak then becomes Weak<T, &A> which is incompatible.~~ Fixed, thank you `@zakarumych!` This PR no longer requires the allocator to be Clone.
* Currently, new_cyclic_in's documentation is almost entirely copy-pasted from new_cyclic, with minor tweaks to make it more accurate (e.g. Rc<T> -> Rc<T, A>). The example section is removed to mitigate redundancy and instead redirects to cyclic_in. Is this appropriate?
* ~~The comments in new_cyclic_in (and much of the implementation) are also copy-pasted from new_cyclic. Would it be better to make a helper method new_cyclic_in_internal that both functions call, with either Global or the custom allocator? I'm not sure if that's even possible, since the internal method would have to return Arc<T, Global> and I don't know if it's possible to "downcast" that to an Arc<T>. Maybe transmute would work here?~~ Done, thanks `@zakarumych`
* Arc::new_cyclic is #[inline], but Rc::new_cyclic is not. Which is preferred?
* nit: does it matter where in the impl block new_cyclic_in is defined?
In the implementation of `force_mut`, I chose performance over safety.
For `LazyLock` this isn't really a choice; the code has to be unsafe.
But for `LazyCell`, we can have a full-safe implementation, but it will
be a bit less performant, so I went with the unsafe approach.
