Current platform's target tuple in std::env::consts

[kornelski]

Implementation for #146295

The terminology follows #125579

I wasn't sure if it's appropriate to refer users to rustc --print target-list in the doc. I haven't seen any other references to compiler flags in std.

I've added a doc alias for TARGET, because that's unfortunately the name users may be more familiar with.

I've picked weird platform examples in the doc to discourage users from trying to parse it.

[rustbot]

r? @Mark-Simulacrum

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

[folkertdev]

This constant isn't used to select anything, right? I think the text here should resemble the docs for pub const ARCH above, so something like:

A string describing ...

[kornelski]

I've meant it in the sense of "std has been compiled with --target=this-string"

[folkertdev]

Right, then I think this is clearer

Suggested change

	/// An identifier used to select the platform for which the standard library was built
	/// A string describing the platform for which the standard library was built

[Mark-Simulacrum]

Perhaps "--target argument passed to rustc for this compilation"? That seems like it ought to match 1:1 to what we're returning.

I'm not sure I'm convinced that this should have HOST in its name -- we don't have that for any of the other constants in this file, and they're all derived from the same source. For a rustc --print argument it makes more sense to differentiate, but here I'm not convinced.

[kornelski]

TUPLE alone would be weird, since without the context it's ambiguous with the tuple types.

it could be a PLATFORM, but that becomes completely disconnected from the --print host-tuple and Cargo's HOST env var.

[Mark-Simulacrum]

std::env::consts::TUPLE doesn't feel easily confusable with the tuple types -- and any such confusion should clear up quickly when actually seeing it's a const with a str value.

I'd personally argue "TARGET" or "HOST" is also not unreasonable naming, given the rest of the constants in that module.

[kornelski]

I've renamed it to HOST, and added explanation when it may not match --target or TARGET.

[Mark-Simulacrum]

Does this have an accepted libs-api ACP? Otherwise it'll need to gate on that.

View changes since this review

[Mark-Simulacrum]

Perhaps "--target argument passed to rustc for this compilation"? That seems like it ought to match 1:1 to what we're returning.

I'm not sure I'm convinced that this should have HOST in its name -- we don't have that for any of the other constants in this file, and they're all derived from the same source. For a rustc --print argument it makes more sense to differentiate, but here I'm not convinced.

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

[tgross35]

I took a look but there doesn't seem to be an ACP for this yet,
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[kornelski]

ACP rust-lang/libs-team#664

@rustbot ready

[programmerjake]

maybe add powerpc64le-... and powerpc64-..., since those can't easily be reconstructed from their parts (unfortunately RustSec decided to delete the upstream repo, making its history very hard to find, here's the corresponding PR)