Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Use captures(address) instead of captures(none) for indirect args #145877

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

Merged
bors merged 1 commit into rust-lang:master from nikic:capture-address
Aug 28, 2025

Conversation

Copy link
Contributor

@nikic nikic commented Aug 26, 2025

While provenance cannot be captured through these arguments, the address / object identity can.

Fixes #137668.

r? @ghost

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 26, 2025
Copy link
Contributor Author

nikic commented Aug 26, 2025

@bors try @rust-timer queue

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Aug 26, 2025 
Use captures(address) instead of captures(none) for indirect args

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 26, 2025

This comment has been minimized.

Copy link

rust-bors bot commented Aug 26, 2025

☀️ Try build successful (CI)
Build commit: 31eb44a (31eb44ad55012c7187d763b5e82bba0f96019687, parent: ace9a74442aec13c75532d34e15d97428056866d)

This comment has been minimized.

Copy link
Collaborator

Finished benchmarking commit (31eb44a): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 0.3% [0.2%, 0.4%] 2
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 -0.7% [-0.9%, -0.6%] 3
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -1.4%, secondary -1.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 2.0% [1.3%, 2.5%] 3
Improvements ✅
(primary)		 -1.4% [-2.3%, -0.7%] 3
Improvements ✅
(secondary)		 -4.1% [-5.4%, -1.6%] 5
All ❌✅ (primary) -1.4% [-2.3%, -0.7%] 3

Cycles

Results (secondary 3.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 3.7% [3.7%, 3.7%] 1
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) - - 0

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 0.1% [0.0%, 0.8%] 59
Regressions ❌
(secondary)		 0.1% [0.0%, 0.1%] 60
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 0.1% [0.0%, 0.8%] 59

Bootstrap: 468.198s -> 467.11s (-0.23%)
Artifact size: 378.40 MiB -> 390.65 MiB (3.24%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 26, 2025 
While provenance cannot be captured through these arguments, the
address / object identity can.
@nikic nikic marked this pull request as ready for review August 26, 2025 15:11
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 26, 2025
Copy link
Contributor

tmiasko commented Aug 26, 2025

@bors r+

Copy link
Collaborator

bors commented Aug 26, 2025

📌 Commit c3ab409 has been approved by tmiasko

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 26, 2025
Copy link
Collaborator

bors commented Aug 28, 2025

⌛ Testing commit c3ab409 with merge d36f964...

Copy link
Collaborator

bors commented Aug 28, 2025

☀️ Test successful - checks-actions
Approved by: tmiasko
Pushing d36f964 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 28, 2025
@bors bors merged commit d36f964 into rust-lang:master Aug 28, 2025
11 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 28, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing cdb45c8 (parent) -> d36f964 (this PR)

Test differences

Show 4 test diffs

Stage 1

  • [ui] tests/ui/codegen/indirect-nocapture.rs: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/codegen/indirect-nocapture.rs: [missing] -> pass (J0)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
 test-dashboard d36f964125163c2e698de5559efefb8217b8b7f0 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. aarch64-apple: 16222.6s -> 6816.4s (-58.0%)
  2. pr-check-1: 1391.7s -> 1695.3s (21.8%)
  3. x86_64-gnu-llvm-19: 2455.3s -> 2887.1s (17.6%)
  4. i686-gnu-2: 5495.8s -> 6353.9s (15.6%)
  5. arm-android: 5867.9s -> 6742.0s (14.9%)
  6. dist-x86_64-apple: 7277.2s -> 8098.8s (11.3%)
  7. dist-aarch64-apple: 6594.5s -> 7330.2s (11.2%)
  8. x86_64-gnu-distcheck: 5085.9s -> 5602.1s (10.1%)
  9. x86_64-gnu-llvm-20-1: 3295.6s -> 3615.3s (9.7%)
  10. x86_64-gnu-llvm-20-2: 5740.5s -> 6293.5s (9.6%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

Copy link
Collaborator

Finished benchmarking commit (d36f964): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)		 0.8% [0.1%, 1.5%] 2
Regressions ❌
(secondary)		 0.4% [0.2%, 1.5%] 14
Improvements ✅
(primary)		 -0.2% [-0.2%, -0.2%] 1
Improvements ✅
(secondary)		 -0.5% [-0.6%, -0.4%] 3
All ❌✅ (primary) 0.5% [-0.2%, 1.5%] 3

Max RSS (memory usage)

Results (primary 3.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 3.1% [3.1%, 3.1%] 1
Regressions ❌
(secondary)		 - - 0
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 3.1% [3.1%, 3.1%] 1

Cycles

Results (secondary 0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 3.8% [3.8%, 3.8%] 1
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 -2.6% [-2.6%, -2.6%] 1
All ❌✅ (primary) - - 0

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 0.1% [0.0%, 0.1%] 5
Regressions ❌
(secondary)		 0.1% [0.0%, 0.1%] 38
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 0.1% [0.0%, 0.1%] 5

Bootstrap: 469.05s -> 469.595s (0.12%)
Artifact size: 391.17 MiB -> 390.67 MiB (-0.13%)

Copy link
Member

dtolnay commented Sep 1, 2025

In dtolnay/itoa#60, this PR showed up as a pretty large regression in core::fmt performance. Is that worth looking more into, or is it an expected inevitable result of a correctness fix?

Copy link
Contributor Author

nikic commented Sep 1, 2025

In dtolnay/itoa#60, this PR showed up as a pretty large regression in core::fmt performance. Is that worth looking more into, or is it an expected inevitable result of a correctness fix?

It's probably worth looking into. It's possible we can mitigate it either with better optimization or just with manual code adjustment.

The likely optimization effect of this change is that some memcpys no longer get eliminated.

Copy link
Member

Kobzol commented Sep 2, 2025

The syn results are noise, and this is a correctness fix anyway.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Sep 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.91.0
Development

Successfully merging this pull request may close these issues.

LLVM nocapture attribute is used incorrectly

AltStyle によって変換されたページ (->オリジナル) /