rustc_llvm: adapt to flattened CLI args in LLVM

[durin42]

This changed in
llvm/llvm-project@e190d07. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19.

@rustbot label: +llvm-main

try-job: x86_64-msvc

[rustbot]

r? @cuviper

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

[nebulark]

Was already going to make a PR for this, as this is due to my change in LLVM, but you were faster.
I think it might make sense to expose the Argv0 and the flattened commandline as args for LLVMRustCreateTargetMachine. That way we can format the string on the rust. What do you think?

Still wip but something like this: master...nebulark:rust_contributing:fix_cl

[durin42]

Was already going to make a PR for this, as this is due to my change in LLVM, but you were faster. I think it might make sense to expose the Argv0 and the flattened commandline as args for LLVMRustCreateTargetMachine. That way we can format the string on the rust. What do you think?

Still wip but something like this: master...nebulark:rust_contributing:fix_cl

I don't really feel strongly - I was mostly trying to not change the interface between the Rust and C++ code until we could really clean house on the old codepath, at which point I'd think harder about it.

We've got a continuous build that builds Rust HEAD against LLVM HEAD as that's what we use internally, so we noticed pretty quickly.

[workingjubilee]

heh, clang-format

[nebulark]

Had another look. There is now a difference in output (besides the now missing erronous "cc1" part). I'd expect this windows-only test to fail:
https://github.com/rust-lang/rust/blob/master/tests/run-make/pdb-buildinfo-cl-cmd/rmake.rs

Previously the arguments were quoted via llvm::sys::printArg:
https://github.com/llvm/llvm-project/blob/41f1b467a29d2ca4e35df37c3aa79a0a8c04bc4f/clang/lib/CodeGen/BackendUtil.cpp#L325-L357
https://github.com/llvm/llvm-project/blob/d703b922961e0d02a5effdd4bfbb23ad50a3cc9f/llvm/lib/Support/Program.cpp#L83-L99

For me it's fine though to leave it as it is, so everything compiles again. I'll make a follow up pr in this case.

[workingjubilee]

@bors try

[bors]

⌛ Trying commit 86d67b7 with merge 784ce4a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 784ce4a (784ce4ac9ba31931d7396b68609803b37d0025cf)

[workingjubilee]

hm!

@bors r+

[bors]

📌 Commit 86d67b7 has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit 86d67b7 with merge 1f9a018...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 1f9a018 to master...

[rust-timer]

Finished benchmarking commit (1f9a018): 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)

Results (primary -3.2%, secondary 2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.5%	[2.0%, 3.0%]	5
Improvements ✅ (primary)	-3.2%	[-3.2%, -3.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.2%	[-3.2%, -3.2%]	1

Cycles

Results (primary 0.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.7%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[0.6%, 0.7%]	2

Binary size

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

Bootstrap: 769.289s -> 770.432s (0.15%)
Artifact size: 341.54 MiB -> 341.54 MiB (-0.00%)