Print regions in type_name.

[nnethercote]

Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like Foo<> and dyn Bar<, A = u32>.

Most regions are erased by the time type_name does its work. So all regions are now printed as '_ in non-optional places. Not perfect, but better than the status quo.

c_name is updated to trim lifetimes from MIR pass names, so that the PASS_NAMES sanity check still works. It is also renamed as simplify_pass_type_name and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.

The commit also renames should_print_region as should_print_optional_region, which makes it clearer that it only applies to some regions.

Fixes #145168.

r? @lcnr

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[nnethercote]

@lcnr: new code is up. Quite a bit has changed.

@rustbot ready

[nnethercote]

I updated again. c_name is now non-const, which is much nicer, and renamed as simplify_pass_type_name.

@rustbot ready

[lcnr]

I updated again. c_name is now non-const, which is much nicer, and renamed as simplify_pass_type_name.

@rustbot ready

i would expect that we've done it in a const block for 👻 perf 👻 reasons? 🤔

@bors2 try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: fc05a4f (fc05a4f44af11286e3ae4b0ab02b85685f709d2b, parent: 1553adfe6884a8f6c28f5a673d3e605535ee0113)

[rust-timer]

Finished benchmarking commit (fc05a4f): comparison URL.

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

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.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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)	1.0%	[0.2%, 4.3%]	70
Regressions ❌ (secondary)	1.2%	[0.1%, 5.3%]	57
Improvements ✅ (primary)	-1.4%	[-1.4%, -1.4%]	1
Improvements ✅ (secondary)	-0.5%	[-1.4%, -0.0%]	3
All ❌✅ (primary)	0.9%	[-1.4%, 4.3%]	71

Max RSS (memory usage)

Results (secondary 4.2%)

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)	4.2%	[1.7%, 5.6%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 3.0%)

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)	4.0%	[3.0%, 6.0%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.8%	[-5.8%, -5.8%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.093s -> 466.402s (0.50%)
Artifact size: 377.76 MiB -> 377.46 MiB (-0.08%)

[bors]

☔ The latest upstream changes (presumably #145366) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

📌 Commit 8296ad0 has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8296ad0 with merge 019bbe7...

[rust-log-analyzer]

The job x86_64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    get(
    ~~~^
        download_info.base_download_url,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        verbose=download_info.verbose,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/checkout/src/bootstrap/bootstrap.py", line 82, in get
    raise RuntimeError("failed verification")
---
    get(
    ~~~^
        download_info.base_download_url,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        verbose=download_info.verbose,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/checkout/src/bootstrap/bootstrap.py", line 82, in get
    raise RuntimeError("failed verification")
---
    get(
    ~~~^
        download_info.base_download_url,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        verbose=download_info.verbose,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/checkout/src/bootstrap/bootstrap.py", line 82, in get
    raise RuntimeError("failed verification")
---
    get(
    ~~~^
        download_info.base_download_url,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        verbose=download_info.verbose,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/checkout/src/bootstrap/bootstrap.py", line 82, in get
    raise RuntimeError("failed verification")
---
    get(
    ~~~^
        download_info.base_download_url,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        verbose=download_info.verbose,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/checkout/src/bootstrap/bootstrap.py", line 82, in get
    raise RuntimeError("failed verification")

[bors]

💔 Test failed - checks-actions

[Zalathar]

@bors retry (flaky download failure?)

[Zalathar]

Scheduling: Prefer an arbitrary rollup=never PR over #144476 if rollup #145519 fails.

@bors p=1

[bors]

⌛ Testing commit 8296ad0 with merge 425a9c0...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 425a9c0 to master...

[github-actions]

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 99ba556 (parent) -> 425a9c0 (this PR)

Test differences

Show 2 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 425a9c0a0e365c0b8c6cfd00c2ded83a73bed9a0 --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. dist-aarch64-linux: 5921.0s -> 8494.0s (43.5%)
2. x86_64-apple-1: 9511.8s -> 12205.0s (28.3%)
3. x86_64-apple-2: 6816.9s -> 5661.5s (-16.9%)
4. dist-armv7-linux: 5002.0s -> 5815.7s (16.3%)
5. dist-ohos-armv7: 4028.1s -> 4544.4s (12.8%)
6. dist-aarch64-msvc: 5457.2s -> 5939.9s (8.8%)
7. aarch64-gnu: 6746.0s -> 7226.4s (7.1%)
8. aarch64-apple: 5131.7s -> 5459.0s (6.4%)
9. dist-x86_64-apple: 10285.1s -> 9642.5s (-6.2%)
10. aarch64-gnu-debug: 4521.9s -> 4798.6s (6.1%)

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.

[rust-timer]

Finished benchmarking commit (425a9c0): comparison URL.

Overall result: ❌ regressions - 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.8%, 0.8%]	1
Regressions ❌ (secondary)	0.5%	[0.1%, 2.0%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[0.8%, 0.8%]	1

Max RSS (memory usage)

Results (primary 0.9%, secondary -3.9%)

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

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

Cycles

Results (secondary 10.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)	14.0%	[2.3%, 21.7%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.9%	[-4.9%, -4.9%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 469.684s -> 470.373s (0.15%)
Artifact size: 377.58 MiB -> 377.75 MiB (0.05%)

[nnethercote]

I think the regressions are just noise. unused-warnings has been bimodal recently.

@rustbot label: +perf-regression-triaged