Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

CC @wesleywiser

Do these tests need to be gated by some kind of minimum cdb version?

They should not. I will try to get some old cdb and verify.

FTR, that is mostly relevant in periods of times where our CI has like a weird mix of 2 cdb versions, e.g. when github gradually rolls out Windows server version bumps. Probably not needed in this case.

I don't really expect a cdb version problem since we're currently not in a cdb transition period, so let's just send this off to see if this passes full CI.

@bors r=@wesleywiser rollup=iffy (debuginfo windows tests)

📌 Commit f86ca11 has been approved by wesleywiser

It is now in the queue for this repository.

I don't really expect a cdb version problem since we're currently not in a cdb transition period, so let's just send this off to see if this passes full CI.

@bors r=@wesleywiser rollup=iffy (debuginfo windows tests)

OK, sorry for the delay. I had trouble with getting the older cdb to be picked up on my machine.

OK, sorry for the delay. I had trouble with getting the older cdb to be picked up on my machine.

Thanks for trying anyway!

⌛ Testing commit f86ca11 with merge 7d9573b...

💔 Test failed - checks-actions

Ah, you may have to add a // ignore-tidy-linelength in the two tests

2025-01-08T15:28:24.6649510Z tidy error: /Users/runner/work/rust/rust/tests/debuginfo/type-names.rs:172: line longer than 100 chars
2025-01-08T15:28:24.6667640Z tidy error: /Users/runner/work/rust/rust/tests/debuginfo/lexical-scope-in-if-let.rs:50: line longer than 100 chars

Fixed, python ./x.py test tidy --bless now does not complain.

⌛ Testing commit 50bdfeb with merge fae14a7...

💔 Test failed - checks-actions

The failure seems genuine. I added a i686-msvc try-job to PR description, please ping me if you'd like to run changes on i686-msvc (this is not a job that's run in PR CI by default).

A cursory glance suggests this is primarily due to pointer-width differences (i686-msvc is 32-bit msvc, so if you have a 64-bit msvc it won't fail locally), where the output is int * vs __int64 * on 64-bit msvc.

@bors try

⌛ Trying commit 75e9b19 with merge b2a0169...

Thanks a lot (for all your help really). I had an isize in one of the new tests which obviously caused an issues.

Sorry for taking so many tries.

Sorry for taking so many tries.

No need to be sorry, debuginfo tests are bound to take Several Attempts™.

Thanks a lot (for all your help really). I had an isize in one of the new tests which obviously caused an issues.

FWIW, this is kinda of a limitation of the present debuginfo test infra. Ideally you'd be able to have a revision matrix of sorts (and thus be able to use isize or usize by explicitly accounting for the ptr width), where on one dimension it's the debuggers [cdb, gdb, lldb], and on the other dimension it might be ptr width [32bit, 64bit]. Then the check would be something possibly like //@[[cdb, 64bit]] check: __int64 * vs //@[[cdb, 32bit]] check: int *. The flattened poor man's version of this revision matrix is the manually flattened 3x2=6 revisions. But I don't really want to implement this in the current compiletest iteration.

☀️ Try build successful - checks-actions
Build commit: b2a0169 (b2a0169a5be4a1d204c7120829e78bda50966a15)

@rustbot ready

@bors r+

📌 Commit 75e9b19 has been approved by wesleywiser

It is now in the queue for this repository.

⌛ Testing commit 75e9b19 with merge 2ae9916...

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 2ae9916 to master...

Finished benchmarking commit (2ae9916): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

Max RSS (memory usage)

Cycles

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

Binary size

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

Bootstrap: 763.215s -> 763.959s (0.10%)
Artifact size: 326.11 MiB -> 326.03 MiB (-0.02%)