Add --print host-tuple to print host target tuple

[Noratrieb]

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

I called it "host-tuple" 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

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

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

Concerns:

• triple vs tuple resolved by Add --print host-tuple to print host target tuple #125579 (comment)

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

#125579 (comment)

[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

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

[workingjubilee]

rebased at Nora's request

[Noratrieb]

mrow thanks
@bors r=davidtwco p=1

[bors]

📌 Commit 7e943ed has been approved by davidtwco

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7e943ed with merge 87916870ed0ecbcd439c5ba0820a4cf8aaf6ace2...

[bors]

💔 Test failed - checks-actions

[Noratrieb]

fixed a trivial semantic conflict where a stray test file was around
@bors r=davidtwco

[bors]

📌 Commit ba48151 has been approved by davidtwco

It is now in the queue for this repository.

[bors]

⌛ Testing commit ba48151 with merge 8ccb78e...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 8ccb78e to master...

[rust-timer]

Finished benchmarking commit (8ccb78e): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary -2.5%, secondary -4.1%)

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)	-	-	0
Improvements ✅ (primary)	-2.5%	[-2.5%, -2.5%]	1
Improvements ✅ (secondary)	-4.1%	[-4.5%, -3.5%]	3
All ❌✅ (primary)	-2.5%	[-2.5%, -2.5%]	1

Cycles

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

Binary size

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

Bootstrap: 781.635s -> 779.462s (-0.28%)
Artifact size: 335.39 MiB -> 335.36 MiB (-0.01%)