Add `--print host-triple` to print host target triple

[Noratrieb]

People often parse -vV output to get to the host triple, which is annoying to do. It's easier to just get it directly.

I called it "host-triple" instead of "host" because it's clearer that it's just the target name. I'm open to different names, but I think this one is fine.

a quick GitHub search for '^host reveals many instances of people doing the parsing, for example:

https://github.com/japaric/xargo/blob/68e0ca57cd90837fe02f262f074182f9cfeb6227/README.md?plain=1#L369 https://github.com/taiki-e/setup-cross-toolchain-action/blob/0e38473b0c562d6db19a98d3ec20a80f7ac189ae/main.sh#L96 https://github.com/taiki-e/cargo-llvm-cov/blob/8a3553b86551eabf9c30c060b1f72a5bbccb98c6/README.md?plain=1#L625 https://github.com/SiliconLabs/cpc-nvm3/blob/43f3ec39709b30700ef7f39d91fa647974323bf1/do.sh#L35

needs a compiler FCP. I could also do an MCP but I think just an FCP here makes the most sense.

[rustbot]

r? @oli-obk

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

[rust-log-analyzer]

The job x86_64-gnu-llvm-17 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#17 exporting to docker image format
#17 sending tarball 32.4s done
#17 DONE 38.1s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-17]
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-17', '--enable-llvm-link-shared', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'change-id=99999999', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-17/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.thin-lto-import-instr-limit := 10
configure: change-id            := 99999999
---

---- [ui] tests/ui/invalid-compile-flags/print.rs stdout ----
diff of stderr:

1 error: unknown print request: `yyyy`
2   |
-   = help: valid print requests are: `all-target-specs-json`, `calling-conventions`, `cfg`, `code-models`, `crate-name`, `deployment-target`, `file-names`, `link-args`, `native-static-libs`, `relocation-models`, `split-debuginfo`, `stack-protector-strategies`, `sysroot`, `target-cpus`, `target-features`, `target-libdir`, `target-list`, `target-spec-json`, `tls-models`
+   = help: valid print requests are: `all-target-specs-json`, `calling-conventions`, `cfg`, `code-models`, `crate-name`, `deployment-target`, `file-names`, `host-triple`, `link-args`, `native-static-libs`, `relocation-models`, `split-debuginfo`, `stack-protector-strategies`, `sysroot`, `target-cpus`, `target-features`, `target-libdir`, `target-list`, `target-spec-json`, `tls-models`
5 


The actual stderr differed from the expected stderr.
The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/invalid-compile-flags/print/print.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args invalid-compile-flags/print.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/invalid-compile-flags/print.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=x86_64-unknown-linux-gnu" "--check-cfg" "cfg(FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/invalid-compile-flags/print" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/invalid-compile-flags/print/auxiliary" "--print" "yyyy"
--- stderr -------------------------------
--- stderr -------------------------------
error: unknown print request: `yyyy`
  |
  = help: valid print requests are: `all-target-specs-json`, `calling-conventions`, `cfg`, `code-models`, `crate-name`, `deployment-target`, `file-names`, `host-triple`, `link-args`, `native-static-libs`, `relocation-models`, `split-debuginfo`, `stack-protector-strategies`, `sysroot`, `target-cpus`, `target-features`, `target-libdir`, `target-list`, `target-spec-json`, `tls-models`



failures:

[workingjubilee]

I would prefer host-tuple, so we don't have to stress about ontologies if the tuple happens to have 2 or 5. I am not the only one who has noticed this, and we also use tools that refer to them as target tuples. ( And as far as I can tell this would be the first stable API that explicitly names the concept beyond "target". )

[bjorn3]

a quick GitHub search for '^host reveals many instances of people doing the parsing, for example:

Cargo also does this.

[oli-obk]

@rfcbot merge

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @Aaron1011
• [x] @cjgillot
• [x] @compiler-errors
• [x] @davidtwco
• [x] @eddyb
• [x] @estebank
• [ ] @jackh726
• [x] @lcnr
• [x] @matthewjasper
• [x] @michaelwoerister
• [x] @nagisa
• [x] @oli-obk
• [x] @petrochenkov
• [x] @pnkfelix
• [x] @wesleywiser

Concerns:

• ~~triple vs tuple~~ resolved by https://github.com/rust-lang/rust/pull/125579#issuecomment--1874449278

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[lcnr]

@rfcbot concern triple vs tuple

https://github.com/rust-lang/rust/pull/125579#issuecomment-2132386452

[michaelwoerister]

As a data point, our existing documentation seem to call it "triple" pretty consistently: https://doc.rust-lang.org/rustc/?search=triple https://doc.rust-lang.org/cargo/index.html?search=triple https://doc.rust-lang.org/reference/?search=triple

[bors]

:umbrella: The latest upstream changes (presumably #125691) made this pull request unmergeable. Please resolve the merge conflicts.

[apiraino]

So, should that be "tuple" or "triple"?

(trying to understand if the concern raised is still standing)

[lcnr]

I personally don't have a strong opinion here and would be open to rescind my concern

• tuple is more accurate as some targets don't use exactly 3 words
• triple is currently the used terminology, though it seems to only be internal

https://doc.rust-lang.org/rustc/platform-support/loongarch-linux.html?highlight=tuple#loongarch-unknown-linux- already uses tuple

@michaelwoerister @workingjubilee does one of you care strongly about either option? It is fairly arbitrary in the end (and its documentation should probably mention the alternative).

One simple way to resolve this might just be a vote on zulip and we pick whatever ends up on top as long as nobody feels very strongly about this: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60--print.20host.5B-tuple.7C-triple.5D.60

[michaelwoerister]

I voted "don't care" on Zulip.

[oli-obk]

r? compiler

[davidtwco]

I don't think there's necessarily a strong consensus from the Zulip poll on terminology here, the team seems to have a slight preference towards host-tuple, do you want to change it to that @Noratrieb?

[rustbot]

Some changes occurred in src/tools/opt-dist

cc @kobzol

These commits modify compiler targets. (See the Target Tier Policy.)

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

[Noratrieb]

@davidtwco I do! I changed it to host-tuple and also updated a bunch (but by far not all) places in the compiler where "triple" is used today.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#16 3.231 Building wheels for collected packages: reuse
#16 3.232   Building wheel for reuse (pyproject.toml): started
#16 3.476   Building wheel for reuse (pyproject.toml): finished with status 'done'
#16 3.477   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132720 sha256=026f3bb0f1aa8090b861fd0a0939cb1a782396d84c8aab7875096557d637a0f6
#16 3.478   Stored in directory: /tmp/pip-ephem-wheel-cache-wxdfvngd/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#16 3.480 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#16 3.869 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#16 3.869 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#16 DONE 4.0s

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

The Miri subtree was changed

cc @rust-lang/miri

[lcnr]

@rfcbot resolve triple vs tuple

[rfcbot]

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

[Noratrieb]

I almost forgot to add documentation, I updated the --print docs in the rustc book with the new value.

[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.

[bors]

:umbrella: The latest upstream changes (presumably #132277) made this pull request unmergeable. Please resolve the merge conflicts.

[zackw]

I hope this isn't baking in further confusion about what "build", "host", and "target" mean when talking about compilation. These terms have longstanding definitions outside of Rust:

The build system is the system where you are compiling something. The host system is the system that the thing you're compiling right now will run on. The target system is the system that the thing you're compiling right now will generate code for. It is only meaningful when the thing you are compiling right now is itself a compiler.

In a native compilation, build and host are the same, but if the thing you're compiling is a cross-compiler, target might be different. In a cross-compilation, the cross-compiler's host is the build system for the thing being compiled, and the cross-compiler's target is the host system for the thing being compiled.

--print host-tuple, therefore, should print the system tuple for the machine where rustc runs, and --print target-tuple should print the system tuple for the machine that rustc is currently configured to generate code for. It is not clear to me whether the PR does this.

[Noratrieb]

yes this is the host, as the name implies

[Noratrieb]

rebased @bors r=davidtwco

[bors]

:pushpin: Commit 0b79d609985aedee6ce5e2952630143c483938fd has been approved by davidtwco

It is now in the queue for this repository.

[workingjubilee]

@bors r-

[Noratrieb]

@bors r=davidtwco

[bors]

:pushpin: Commit 97d18b264151217cbbbbde214551090be6c060bd has been approved by davidtwco

It is now in the queue for this repository.