Add a clang subcommand.

[jonmeow]

This makes something like bazel run :toolchain -- clang -- -c test.cpp work, because that can be run in-process. Note that bazel run :toolchain -- clang -- test.cpp still requires subprocessing, and does not work.

Note, the vision here is that we are trying to align how clang and carbon compile c++ code. This is work towards intertwining command execution.

[jonmeow]

Note, I'm sending this to you as-is because I want to make sure the subprocessing behavior aligns with your expectations. I believe this is getting equivalent behavior as to clang:

╚╡strace -fe trace=clone,fork,execve clang -c test.cpp
execve("/usr/lib/llvm-16/bin/clang", ["clang", "-c", "test.cpp"], 0x7ffc84ae67e0 /* 41 vars */) = 0
+++ exited with 0 +++

╚╡strace -fe trace=clone,fork,execve clang test.cpp
execve("/usr/lib/llvm-16/bin/clang", ["clang", "test.cpp"], 0x7ffd23f946f8 /* 41 vars */) = 0
strace: Process 1074218 attached
[pid 1074218] execve("/usr/lib/llvm-16/bin/clang", ["/usr/lib/llvm-16/bin/clang", "-cc1", "-triple", "x86_64-pc-linux-gnu", "-emit-obj", "-mrelax-all", "-disable-free", "-clear-ast-before-backend", "-disable-llvm-verifier", "-discard-value-names", "-main-file-name", "test.cpp", "-mrelocation-model", "pic", "-pic-level", "2", "-pic-is-pie", "-mframe-pointer=all", "-fmath-errno", "-ffp-contract=on", "-fno-rounding-math", "-mconstructor-aliases", "-funwind-tables=2", "-target-cpu", "x86-64", "-tune-cpu", "generic", "-mllvm", "-treat-scalable-fixed-error-as-w"..., "-debugger-tuning=gdb", "-fcoverage-compilation-dir=/usr/"..., "-resource-dir", ...], 0x7fffd11b9750 /* 41 vars */) = 0
[pid 1074218] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1074218, si_uid=18553, si_status=0, si_utime=2 /* 0.02 s */, si_stime=2 /* 0.02 s */} ---
strace: Process 1074219 attached
[pid 1074219] execve("/usr/bin/ld", ["/usr/bin/ld", "-pie", "--hash-style=gnu", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o", "a.out", "/lib/x86_64-linux-gnu/Scrt1.o", "/lib/x86_64-linux-gnu/crti.o", "/usr/lib/gcc/x86_64-linux-gnu/14"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/x86_64-linux-gnu", "-L/lib/../lib64", "-L/usr/lib/x86_64-linux-gnu", "-L/usr/lib/../lib64", "-L/usr/lib/llvm-16/bin/../lib", "-L/lib", "-L/usr/lib", "/tmp/test-46b600.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", ...], 0x7fffd11b9750 /* 41 vars */) = 0
[pid 1074219] +++ exited with 0 +++

[chandlerc]

Yeah, all of this matches my expectation.

Worth adding a small test that checks the whole -c flow maybe? Also left an optional TODO idea, but that's not blocking or especially important.

[chandlerc]

This makes sense to me.

I have an idea of another step we may want to eventually try to take here, but emphasis on "may" (not at all sure) and "eventually". =] Suggesting as a TODO in case you want to capture it and/or tweak the wording in the code. But also happy to just leave for discussion or the future.

Suggested change

	// When there's only one command being run, this will run it in-process.
	// However, a `clang` invocation may cause multiple `cc1` invocations, which
	// still subprocess.
	// When there's only one command being run, this will run it in-process.
	// However, a `clang` invocation may cause multiple `cc1` invocations, which
	// still subprocess.
	//
	// TODO: It would be nice to find a way to set up the driver's understanding
	// of the executable name in a way that causes the multiple `cc1` invocations
	// to actually result in `carbon clang -- ...` invocations (even if as
	// subprocesses). This may dovetail with having symlinks that redirect to a
	// busybox of LLD as well, and having even the subprocesses consistently run
	// the Carbon install toolchain and not a system toolchain whenever possible.

Maybe this is already part of what you're thinking about with busyboxing the linker too, feel free to skip the TODO if already part of your larger plans.