re-use `self.get_all_attrs` result for pass indirectly attribute
Could be a fix for a potential performance regression reported here https://github.com/rust-lang/rust/pull/144529#issuecomment-3491236458. Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor.
r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)
[rustdoc] Replace `print` methods with functions to improve code readability
We have a lot of `print` methods, making it quite tricky to know what the types we're manipulating are.
We did something similar with `Clean` trait a few years ago (the first PR was https://github.com/rust-lang/rust/pull/99638, followed by a lot of them).
Each commit replaces one type for easier review.
r? `````@yotamofek`````
Fix rust-by-example spanish translation
A spanish translation was added in https://github.com/rust-lang/rust-by-example/pull/1910, but the upstream integration was never added.
```@marioidival,``` I assume you intended for this to go live?
update isolate_highest_one for NonZero<T>
## Rationale
Let `x = self` and
`m = (((1 as $Int) << (<$Int>::BITS - 1)).wrapping_shr(self.leading_zeros()))`
Then the previous code computed `NonZero::new_unchecked(x & m)`.
Since `m` has exactly one bit set (the most significant 1-bit of `x`), `(x & m) == m`.
Therefore, the masking step was redundant.
The shift is safe and does not need wrapping because:
* `self.leading_zeros() < $Int::BITS` because `self` is non-zero.
* The result of `unchecked_shr` is non-zero, satisfying the `NonZero` invariant. if wrapping happens we would be violating `NonZero` invariants.
why this micro optimization?
the old code was suboptimal it duplicated `$Int`’s isolate_highest_one logic instead of delegating to it. Since the type already wraps `$Int`, either delegation should be used for clarity or, if keeping a custom implementation, it should be optimized as above.
Add -Zannotate-moves for profiler visibility of move/copy operations (codegen)
**Note:** this is an alternative implementation of https://github.com/rust-lang/rust/pull/147206; rather than being a MIR transform, it adds the annotations closer to codegen. It's functionally the same but the implementation is lower impact and it could be more correct.
---
This implements a new unstable compiler flag `-Zannotate-moves` that makes move and copy operations visible in profilers by creating synthetic debug information. This is achieved with zero runtime cost by manipulating debug info scopes to make moves/copies appear as calls to `compiler_move<T, SIZE>` and `compiler_copy<T, SIZE>` marker functions in profiling tools.
This allows developers to identify expensive move/copy operations in their code using standard profiling tools, without requiring specialized tooling or runtime instrumentation.
The implementation works at codegen time. When processing MIR operands (`Operand::Move` and `Operand::Copy`), the codegen creates an `OperandRef` with an optional `move_annotation` field containing an `Instance` of the appropriate profiling marker function. When storing the operand, `store_with_annotation()` wraps the store operation in a synthetic debug scope that makes it appear inlined from the marker.
Two marker functions (`compiler_move` and `compiler_copy`) are defined in `library/core/src/profiling.rs`. These are never actually called - they exist solely as debug info anchors.
Operations are only annotated if:
- We're generating debug info and the feature is enabled.
- Meets the size threshold (default: 65 bytes, configurable via `-Zannotate-moves=SIZE`), and is non-zero
- Has a memory representation
This has a very small size impact on object file size. With the default limit it's well under 0.1%, and even with a very small limit of 8 bytes it's still ~1.5%. This could be enabled by default.
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
Liveness: Cache the set of string constants for suggestions.
Even on a slow diagnostic path, listing all the constants in MIR can be expensive, so cache it.
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```
This implements a new unstable compiler flag `-Zannotate-moves` that makes
move and copy operations visible in profilers by creating synthetic debug
information. This is achieved with zero runtime cost by manipulating debug
info scopes to make moves/copies appear as calls to `compiler_move<T, SIZE>`
and `compiler_copy<T, SIZE>` marker functions in profiling tools.
This allows developers to identify expensive move/copy operations in their
code using standard profiling tools, without requiring specialized tooling
or runtime instrumentation.
The implementation works at codegen time. When processing MIR operands
(`Operand::Move` and `Operand::Copy`), the codegen creates an `OperandRef`
with an optional `move_annotation` field containing an `Instance` of the
appropriate profiling marker function. When storing the operand,
`store_with_annotation()` wraps the store operation in a synthetic debug
scope that makes it appear inlined from the marker.
Two marker functions (`compiler_move` and `compiler_copy`) are defined
in `library/core/src/profiling.rs`. These are never actually called -
they exist solely as debug info anchors.
Operations are only annotated if the type:
- Meets the size threshold (default: 65 bytes, configurable via
`-Zannotate-moves=SIZE`)
- Has a non-scalar backend representation (scalars use registers,
not memcpy)
This has a very small size impact on object file size. With the default
limit it's well under 0.1%, and even with a very small limit of 8 bytes
it's still ~1.5%. This could be enabled by default.
