Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#145768 (Offload device)
- rust-lang/rust#145992 (Stabilize `vec_deque_pop_if`)
- rust-lang/rust#147416 (Early return if span is from expansion so we dont get empty span and ice later on)
- rust-lang/rust#147808 (btree: cleanup difference, intersection, is_subset)
- rust-lang/rust#148520 (style: Use binary literals instead of hex literals in doctests for `highest_one` and `lowest_one`)
- rust-lang/rust#148559 (Add typo suggestion for a misspelt Cargo environment variable)
- rust-lang/rust#148567 (Fix incorrect precedence caused by range expression)
- rust-lang/rust#148570 (Fix mismatched brackets in generated .dir-locals.el)
- rust-lang/rust#148575 (fix dev guide link in rustc_query_system/dep_graph/README.md)
- rust-lang/rust#148578 (core docs: add notes about availability of `Atomic*::from_mut_slice`)
- rust-lang/rust#148603 (Backport 1.91.1 relnotes to main)
- rust-lang/rust#148609 (Sync str::rsplit_once example with str::split_once)
r? `@ghost`
`@rustbot` modify labels: rollup
Sync str::rsplit_once example with str::split_once
This adds `"cfg=".rsplit_once('=')` case to `rsplit_once` example, bringing it in sync with example for `split_once`. For consistency and to make life easier for ones who want to ensure bahaviour of this specific edge case.
Backport 1.91.1 relnotes to main
Backport of the release notes from https://github.com/rust-lang/rust/pull/148593 to the main branch. This should land before Monday so that the automation creates the GitHub release.
Fix incorrect precedence caused by range expression
Fixesrust-lang/rust#148344
The testcase `tests/ui/feature-gates/feature-gate-new_range` is also fixed.
style: Use binary literals instead of hex literals in doctests for `highest_one` and `lowest_one`
For example, I think it's easier to understand that the index of the highest bit set to one in `16` is `4` as `0b10000` than as `0x10`.
```rust
assert_eq!(0x10_u64.highest_one(), Some(4));
```
Instead of:
```rust
assert_eq!(0b10000_u64.highest_one(), Some(4));
```
rust-lang/rust#145203
Early return if span is from expansion so we dont get empty span and ice later on
Fixes https://github.com/rust-lang/rust/issues/147255
The problem original was from that stmt.span was from expansion and it span was bigger than right part which is block.span, so it causes empty span and panic later on, I decided to add checks for both of them to be on the safe side
r? `@fmease` (you were in discussion on this issue so I decided to assign you, feel free to reroll)
Offload device
LLVM's offload functionality usually expects an extra dyn_ptr argument. We could avoid it,b ut likely gonna need it very soon in one of the follow-up PRs (e.g. to request shared memory). So we might as well already add it.
This PR adds a %dyn_ptr ptr to GPUKernel ABI functions, if the offload feature is enabled.
WIP
r? ```@ghost```
run-make tests: use edition 2024
Bump run-make tests to edition 2024 to prevent test failures when using 2024 idioms in included code, such as I ran into here: https://github.com/rust-lang/rust/pull/147808.
Fix invalid tag closing when leaving expansion "original code"
Fixesrust-lang/rust#148184.
Problem was that in case an element inside the expansion's "original" element was not closed, this element would get its `pending_exit` field set to `true`, removing it when the next non-mergeable item gets pushed instead of being put inside it, and then next `exit_elem` would try to exit an empty class queue.
r? ```@notriddle```
add extend_front to VecDeque with specialization like extend
ACP: https://github.com/rust-lang/libs-team/issues/658
Tracking issue: rust-lang/rust#146975
_Text below was written before opening the ACP_
Feature was requested in rust-lang/rust#69939, I recently also needed it so decided to implement it as my first contribution to the Rust standard library. I plan on doing more but wanted to start with a small change.
Some questions I had (both on implementation and design) with answers:
- Q: `extend` allows iterators that yield `&T` where `T` is `Clone`, should extend_front do too?
A: No, users can use [`copied`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.copied) and/or [`cloned`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.cloned).
- Q: Does this need a whole new trait like Extend or only a method on `VecDeque`?
A: No, see ACP.
- Q: How do I deal with all the code duplication? Most code is similar to that of `extend`, maybe there is a nice way to factor out the code around `push_unchecked`/`push_front_unchecked`.
Will come back to this later.
- Q: Why are certain things behind feature gates, `cfg(not(test))` like `vec::IntoIter` here and `cfg(not(no_global_oom_handling))` like `Vec::extend_from_within`? (I am also looking at implementing `VecDeque::extend_from_within`)
A: See https://github.com/rust-lang/rust/pull/146861#pullrequestreview-3250163369
- Q: Should `extend_front` act like repeated pushes to the front of the queue? This reverses the order of the elements. Doing it different might incur an extra move if the iterator length is not known up front (where do you start placing elements in the buffer?).
A: `extend_front` acts like repeated pushes, `prepend` preserves the element order, see ACP or tracking issue.
Add num_children method to some gdb pretty-printers
gdb doesn't have a way to know when an object hasn't yet been initialized, and in this case, if a pretty-printer returns an absurd number of children, this can result in apparent hangs in some modes. This came up specifically with DAP, see this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=33594
This patch (mostly) addresses this potential issue in the Rust pretty-printers, by adding 'num_children' methods. In particular a method like this is added when the number of children is variable and also relatively easy to compute. (I.e., I didn't attempt the btree printers.)
Supplying num_children is good for DAP regardless of the initialization problem, because DAP requires a count of child objects and this is more efficient than enumerating the children, which is gdb's fallback approach.
Minor fixes to StdNonZeroNumberProvider for gdb
While looking at the pretty-printers, I found a few minor oddities in StdNonZeroNumberProvider.
First, gdb.Type.fields() already returns a sequence, so there's no need to call list().
Second, it's more idiomatic for the (somewhat misnamed) to_string method to simply return the underlying gdb.Value. This also lets gdb apply whatever formats were passed to `print`, as the new test shows.
Third, there's no need to use the field's name when looking up a field in a value, the gdb.Field itself can be used.
std-detect: improve detect macro docs
Specifically, document that the detect macros expand to `true` when the feature is statically enabled.
Now that we have a bunch of these macros, perhaps we should streamline further how they are documented?
r? ``@Amanieu``
Add default sanitizers to TargetOptions
Some sanitizers are part of a system's ABI, like the shadow call stack on Aarch64 and RISC-V Fuchsia. Typically ABI options have other spellings, but LLVM has, for historical reasons, marked this as a sanitizer instead of an alternate ABI option. As a result, Fuchsia targets may not be compiled against the correct ABI unless this option is set. This hasn't caused correctness problems, since the backend reserves the SCS register, and thus preserves its value. But this is an issue for unwinding, as the SCS will not be an array of PCs describing the call complete call chain, and will have gaps from callers that don't use the correct ABI.
In the long term, I'd like to see all the sanitizer configs that all frontends copy from clang moved into llvm's libFrontend, and exposed so that frontend consumers can use a small set of simple APIs to use sanitizers in a consistent way across the LLVM ecosystem, but that work is not yet ready today.
Fix ICE from lit_to_mir_constant caused by type error
Fixesrust-lang/rust#148515
we still need to mark that there were errors to prevent later phases (like MIR building) from proceeding.
bors