-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Rollup of 5 pull requests #148496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Rollup of 5 pull requests #148496
+1,184
−127
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The tests fail on s390x and presumably other big-endian systems, due to check of raw alloc values in the MIR output. To fix the tests remove the raw bytes from the MIR output (via: compile-flags: -Zdump-mir-exclude-alloc-bytes) and update the matching diffs.
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.
The first was a warning:
```
Testing stage2 {rustc_parse_format} (aarch64-apple-darwin)
Compiling rustc_index v0.0.0 (/Users/ci/project/compiler/rustc_index)
error: extern crate `smallvec` is unused in crate `rustc_index`
--> compiler/rustc_index/src/lib.rs:2:1
|
2 | #![cfg_attr(all(feature = "nightly", test), feature(stmt_expr_attributes))]
| ^
|
= help: remove the dependency or add `use smallvec as _;` to the crate root
= note: `-D unused-crate-dependencies` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unused_crate_dependencies)]`
error: could not compile `rustc_index` (lib) due to 1 previous error
```
The second was that `type_ir_macros` didn't fully specify its
dependencies:
```
Testing stage1 {rustc_type_ir_macros} (aarch64-apple-darwin)
Compiling rustc_type_ir_macros v0.0.0 (/Users/jyn/src/ferrocene3/compiler/rustc_type_ir_macros)
error[E0432]: unresolved import `syn::visit_mut`
--> compiler/rustc_type_ir_macros/src/lib.rs:2:10
|
2 | use syn::visit_mut::VisitMut;
| ^^^^^^^^^ could not find `visit_mut` in `syn`
|
note: found an item that was configured out
--> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.106/src/lib.rs:880:21
|
878 | #[cfg(feature = "visit-mut")]
| --------------------- the item is gated behind the `visit-mut` feature
879 | #[cfg_attr(docsrs, doc(cfg(feature = "visit-mut")))]
880 | pub use crate::gen::visit_mut;
| ^^^^^^^^^
error[E0433]: failed to resolve: could not find `visit_mut` in `syn`
--> compiler/rustc_type_ir_macros/src/lib.rs:206:18
|
206 | syn::visit_mut::visit_type_path_mut(self, i);
| ^^^^^^^^^ could not find `visit_mut` in `syn`
|
note: found an item that was configured out
--> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.106/src/lib.rs:880:21
|
878 | #[cfg(feature = "visit-mut")]
| --------------------- the item is gated behind the `visit-mut` feature
879 | #[cfg_attr(docsrs, doc(cfg(feature = "visit-mut")))]
880 | pub use crate::gen::visit_mut;
| ^^^^^^^^^
```
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: add a lifetime to the impl block and use it in the self type and associated type
|
LL ~ impl<'a> IntoIterator for &'a S {
LL ~ type Item = &'a T;
|
```
Move the previous long message to a note and use a shorter primary message:
```
error: missing lifetime in associated type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
…eril Tweak output of missing lifetime on associated type Follow up to rust-lang#135602. Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide. ``` error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration --> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18 | 7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>; | ^^^^ lifetimes do not match type in trait | ::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5 | 292 | type IntoIter: Iterator<Item = Self::Item>; | ------------------------------------------ lifetimes in impl do not match this type in trait ``` Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime. ``` error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type --> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17 | LL | type Item = &T; | ^ this lifetime must come from the implemented type | help: add a lifetime to the impl block and use it in the self type and associated type | LL ~ impl<'a> IntoIterator for &'a S { LL ~ type Item = &'a T; | ``` Move the previous long message to a note and use a shorter primary message: ``` error: missing lifetime in associated type --> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17 | LL | impl<'a> IntoIterator for &S { | ---- there is a named lifetime specified on the impl block you could use ... LL | type Item = &T; | ^ this lifetime must come from the implemented type | note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL help: consider using the lifetime from the impl block | LL | type Item = &'a T; | ++ ``` r? ````@Nadrieril````
…saethlin Add -Zannotate-moves for profiler visibility of move/copy operations (codegen) **Note:** this is an alternative implementation of rust-lang#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.
…=saethlin Fix tests for big-endian The tests fail on s390x and presumably other big-endian systems, due to check of raw alloc values in the MIR output. To fix the tests remove the raw bytes from the MIR output (via: compile-flags: -Zdump-mir-exclude-alloc-bytes) and update the matching diffs.
compiler: Fix a couple issues around cargo feature unification cc rust-lang#148266. this doesn't fix all the issues (`rustc_public` and `rustc_transmute` still emit warnings when tested individually), but it fixes all the simple ones. To fix rustc_public I will probably need help from ```@AlexanderPortland``` or ```@makai410``` to make sure I am not accidentally cfg-ing out items that are meant to be public. To fix `rustc_transmute`, I will need to know (from ```@jswrenn``` ?) in what context the `rustc` cargo feature is disapled. To reproduce the issues, you can run `x test rustc_{transmute,public}` locally. --- The first issue I fixed was a warning in `rustc_index`: ``` Testing stage2 {rustc_parse_format} (aarch64-apple-darwin) Compiling rustc_index v0.0.0 (/Users/ci/project/compiler/rustc_index) error: extern crate `smallvec` is unused in crate `rustc_index` --> compiler/rustc_index/src/lib.rs:2:1 | 2 | #![cfg_attr(all(feature = "nightly", test), feature(stmt_expr_attributes))] | ^ | = help: remove the dependency or add `use smallvec as _;` to the crate root = note: `-D unused-crate-dependencies` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_crate_dependencies)]` error: could not compile `rustc_index` (lib) due to 1 previous error ``` The second was that `type_ir_macros` didn't fully specify its dependencies: ``` Testing stage1 {rustc_type_ir_macros} (aarch64-apple-darwin) Compiling rustc_type_ir_macros v0.0.0 (/Users/jyn/src/ferrocene3/compiler/rustc_type_ir_macros) error[E0432]: unresolved import `syn::visit_mut` --> compiler/rustc_type_ir_macros/src/lib.rs:2:10 | 2 | use syn::visit_mut::VisitMut; | ^^^^^^^^^ could not find `visit_mut` in `syn` | note: found an item that was configured out --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.106/src/lib.rs:880:21 | 878 | #[cfg(feature = "visit-mut")] | --------------------- the item is gated behind the `visit-mut` feature 879 | #[cfg_attr(docsrs, doc(cfg(feature = "visit-mut")))] 880 | pub use crate::gen::visit_mut; | ^^^^^^^^^ error[E0433]: failed to resolve: could not find `visit_mut` in `syn` --> compiler/rustc_type_ir_macros/src/lib.rs:206:18 | 206 | syn::visit_mut::visit_type_path_mut(self, i); | ^^^^^^^^^ could not find `visit_mut` in `syn` | note: found an item that was configured out --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.106/src/lib.rs:880:21 | 878 | #[cfg(feature = "visit-mut")] | --------------------- the item is gated behind the `visit-mut` feature 879 | #[cfg_attr(docsrs, doc(cfg(feature = "visit-mut")))] 880 | pub use crate::gen::visit_mut; | ^^^^^^^^^ ```
…uffix, r=fee1-dead
Dogfood `trim_{suffix|prefix}` in compiler
cc rust-lang#142312
|
@bors r+ rollup=never p=5 |
bors
added a commit
that referenced
this pull request
Nov 4, 2025
Rollup of 5 pull requests Successful merges: - #145314 (Tweak output of missing lifetime on associated type) - #147803 (Add -Zannotate-moves for profiler visibility of move/copy operations (codegen)) - #147925 (Fix tests for big-endian) - #148341 (compiler: Fix a couple issues around cargo feature unification) - #148371 (Dogfood `trim_{suffix|prefix}` in compiler) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
rollup
A PR which is a rollup
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
T-rustdoc-frontend
Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
trim_{suffix|prefix}in compiler #148371 (Dogfoodtrim_{suffix|prefix}in compiler)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup