Remove current code for embedding command-line args in PDB

[Zalathar]

The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output.

This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added.

---

Those concerns include:

• The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the large-workspace benchmark.
  • See (EXPERIMENT) Perf experiments for target-machine command-line quoting #146804 (comment) for an example of the perf consequences of skipping all that work.
  • This overhead occurs even when building for targets or configurations that don't emit PDB output.
• Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation.
  • Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output.
• Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard.
  • LF_BUILDINFO introduces non-determinism to Windows rlib builds #128842

---

Relevant PRs:

• Add CL and CMD into to pdb debug info #113492
• rustc_llvm: adapt to flattened CLI args in LLVM #130446
• rustc_llvm: Fix flattened CLI args #131805
• cg_llvm: Move target machine command-line quoting from C++ to Rust #146700
• Compute quoted args for debuginfo at most once per session #146973

Zulip thread:

• https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211

---

According to #96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. It appears that Live++ doesn't actually support Rust yet, so it's possible that there aren't any existing workflows for this removal to break.

In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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]

@bors try @rust-timer queue

[Zalathar]

Looks flaky. Let’s try again.

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: e4d7ba7 (e4d7ba78e779e732d68b8f16c4348091513822d2, parent: 7cfd7d328b14b936c7ffede92cacebe8557c6388)

[rust-timer]

Finished benchmarking commit (e4d7ba7): comparison URL.

Overall result: ✅ 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
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.2%]	8
Improvements ✅ (secondary)	-3.7%	[-20.6%, -0.7%]	17
All ❌✅ (primary)	-0.3%	[-0.5%, -0.2%]	8

Max RSS (memory usage)

Results (primary 4.1%)

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

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

Cycles

Results (secondary -2.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.4%	[2.0%, 2.7%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.2%	[-7.2%, -2.1%]	11
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 469.935s -> 470.607s (0.14%)
Artifact size: 388.04 MiB -> 388.06 MiB (0.01%)

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Zalathar]

(Rebased; no changes.)

Also, one of the ui-fulldeps tests needed a trivial fix.

[wesleywiser]

@bors r+

[bors]

📌 Commit 98c95c9 has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit 98c95c9 with merge 96fe3c3...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 96fe3c3 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 37ec98f (parent) -> 96fe3c3 (this PR)

Test differences

Show 3 test diffs

Stage 1

• [run-make] tests/run-make/pdb-buildinfo-cl-cmd: ignore (only executed when the operating system and target environment are windows-msvc) -> [missing] (J2)

Stage 2

• [run-make] tests/run-make/pdb-buildinfo-cl-cmd: ignore (only executed when the operating system and target environment are windows-msvc) -> [missing] (J0)
• [run-make] tests/run-make/pdb-buildinfo-cl-cmd: pass -> [missing] (J1)

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-debug, aarch64-gnu-llvm-20-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, dist-various-1, i686-gnu-1, i686-gnu-nopt-1, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-gcc, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1
• J1: aarch64-msvc-1, i686-msvc-1, x86_64-msvc-1
• J2: x86_64-gnu-llvm-20-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 96fe3c31c2ec385f3d3263346bcdde3d118cdaf6 --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. x86_64-gnu-llvm-20: 2328.3s -> 2794.9s (20.0%)
2. dist-aarch64-apple: 7586.1s -> 6360.8s (-16.2%)
3. x86_64-gnu-llvm-20-1: 3198.1s -> 3611.7s (12.9%)
4. aarch64-apple: 8042.2s -> 9058.7s (12.6%)
5. aarch64-gnu-llvm-20-2: 2269.8s -> 2531.4s (11.5%)
6. x86_64-rust-for-linux: 2744.5s -> 3049.8s (11.1%)
7. tidy: 187.7s -> 205.5s (9.5%)
8. dist-apple-various: 3722.5s -> 4071.3s (9.4%)
9. pr-check-1: 1832.4s -> 1996.8s (9.0%)
10. x86_64-gnu-llvm-20-3: 6271.2s -> 6694.2s (6.7%)

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 (96fe3c3): 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)	1.2%	[1.2%, 1.2%]	1
Regressions ❌ (secondary)	1.2%	[1.2%, 1.2%]	1
Improvements ✅ (primary)	-0.3%	[-0.4%, -0.2%]	6
Improvements ✅ (secondary)	-4.2%	[-20.9%, -0.3%]	14
All ❌✅ (primary)	-0.1%	[-0.4%, 1.2%]	7

Max RSS (memory usage)

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

Cycles

Results (secondary -5.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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.0%	[-6.6%, -2.9%]	5
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 472.516s -> 472.935s (0.09%)
Artifact size: 388.62 MiB -> 388.69 MiB (0.02%)

[Zalathar]

The syn regressions are pretty clearly noise.