Fix compiletest path-related issues on Windows

[Walnut356]

fixes the issues mentioned here. With these changes I'm able to run ./x test tests/debuginfo on x86_64-pc-windows-gnu without any issues.

As mentioned in the link though, there are 3 tests that currently fail when run on windows, but that pass on whatever CI targets actually run tests/debuginfo.

I'm not sure if target_run_lib_path really needs to be prepended on all targets (it absolutely does for Windows though), but i figure it can't hurt. Also made sure the path separators are correct per-platform.

The lldb_batchmode change prevents the tests from hanging forever. I'm not 100% sure why this hasn't been a problem so far. Maybe just due to the version of LLDB used on the test runner? I haven't done too much testing, but the situation is...weird. I opened an issue about it in the LLVM repo.

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

r? @clubby789

rustbot has assigned @clubby789.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @jieyouxu, @oli-obk, @wesleywiser, bootstrap
• @jieyouxu, @oli-obk, @wesleywiser, bootstrap expanded to 8 candidates
• Random selection from Mark-Simulacrum, clubby789

[jieyouxu]

r? me

[jieyouxu]

Changes themselves look fine, I'll try it locally on Windows a bit later

View changes since this review

[jieyouxu]

Thanks. I tested this on MSYS2 MINGW64 locally with lldb 22.1.2 via mingw-w64-clang-x86_64-lldb. At least things seem no more broken than before. I can reproduce the same 3 test failures.

@bors r+ rollup=iffy

View changes since this review

[rust-bors]

📌 Commit c9e3d31 has been approved by jieyouxu

It is now in the queue for this repository.

[jieyouxu]

As mentioned in the link though, there are 3 tests that currently fail when run on windows, but that pass on whatever CI targets actually run tests/debuginfo.

AFAIK only aarch64-apple currently runs debuginfo tests against lldb, which likely explains why these 3 tests fail locally for you and me but doesn't fail CI collectively.

[rust-bors]

☀️ Test successful - CI
Approved by: jieyouxu
Duration: 3h 7m 44s
Pushing fff9e44 to main...

[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 906ca7f (parent) -> fff9e44 (this PR)

Test differences

Show 3 test diffs

3 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 fff9e4432233df859e4fadb30ab7f0eda22580a6 --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. pr-check-1: 36m 10s -> 28m 20s (-21.7%)
2. dist-apple-various: 1h 58m -> 1h 33m (-21.3%)
3. pr-check-2: 42m 54s -> 35m 34s (-17.1%)
4. x86_64-rust-for-linux: 54m 18s -> 46m 25s (-14.5%)
5. i686-gnu-2: 1h 43m -> 1h 30m (-12.5%)
6. x86_64-gnu-gcc: 1h 10m -> 1h 2m (-11.3%)
7. i686-gnu-1: 2h 24m -> 2h 8m (-11.1%)
8. x86_64-gnu-tools: 1h 4m -> 57m 30s (-10.6%)
9. dist-x86_64-apple: 1h 44m -> 1h 55m (+10.2%)
10. x86_64-gnu-llvm-22-2: 1h 45m -> 1h 35m (-9.8%)

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 (fff9e44): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary -3.4%)

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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-3.4%, -3.4%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 487.434s -> 488.874s (0.30%)
Artifact size: 395.29 MiB -> 395.28 MiB (-0.00%)