compiletest: Run the lldb_batchmode.py script in LLDB's embedded Python

[Zalathar]

Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the lldb command directly.

Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings.

However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the script command.

[rustbot]

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

[Zalathar]

Big thanks to @Walnut356 for suggesting the use of LLDB's embedded Python.

cc @jieyouxu @xSetech

This may be a useful alternative to some of the changes proposed in:

• bootstrap: respect build.python on macOS #148636
• compiletest: don't pickup a Python from PYTHONPATH in debuginfo #148646

r? jieyouxu

[rustbot]

jieyouxu is currently at their maximum review capacity.
They may take a while to respond.

[jieyouxu]

@bors try jobs=aarch64-apple

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9d85981 (9d85981868d8787740cfbd23500af90eabf8b01e, parent: 4e0baae06da3c29210ba3620db5b01bcb5aba38a)

[Zalathar]

Pushed a small tweak to explicitly specify that the script is in Python, and not some other language.

Doesn't seem to be needed in practice, but perhaps it will avoid headaches someday.

[jieyouxu]

Thanks, this makes a lot of sense than trying to figure out some random Python from the environment... I tried this locally and it seems to work. Let's give this a try, at worst we can revert if any cursed issues crop up.

View changes since this review

[jieyouxu]

@bors r+ rollup=never

[bors]

📌 Commit dca8be9 has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit dca8be9 with merge 00426d6...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 00426d6 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 5f666a6 (parent) -> 00426d6 (this PR)

Test differences

Show 4 test diffs

Stage 2

• [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression or LLVM is not the default codegen backend) -> pass (J0)

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

Job group index

• J0: x86_64-gnu-nopt

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 00426d642ad6a8c6192bf517702a68b0a8001547 --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: 2549.4s -> 1468.1s (-42.4%)
2. x86_64-rust-for-linux: 4160.1s -> 2584.6s (-37.9%)
3. pr-check-2: 3160.3s -> 2130.4s (-32.6%)
4. x86_64-gnu-tools: 4881.6s -> 3335.8s (-31.7%)
5. aarch64-gnu-debug: 5871.7s -> 4025.2s (-31.4%)
6. x86_64-gnu-debug: 10143.7s -> 6965.4s (-31.3%)
7. x86_64-gnu-gcc: 4389.4s -> 3072.5s (-30.0%)
8. dist-aarch64-apple: 5714.9s -> 7342.9s (+28.5%)
9. armhf-gnu: 6693.1s -> 4910.3s (-26.6%)
10. arm-android: 7492.2s -> 5538.8s (-26.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 (00426d6): 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 (primary 2.1%)

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

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

Binary size

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

Bootstrap: 475.073s -> 476.293s (0.26%)
Artifact size: 391.33 MiB -> 391.34 MiB (0.00%)