rustc: add a `--print targets` command

[japaric]

that prints a list of all the triples supported by the --target flag

r? @alexcrichton

[alexcrichton]

Would it be possible to not duplicate this list with the one below? Could the macro somehow use something like stringify! to build a vector, or could an iterator macro be used?

[nodakai]

It seems tricky to handle mixture of hyphens and an underscore...

[nodakai]

I think "x86_64-w64-mingw32" is an alias for "x86_64-pc-windows-gnu" and should be included in the list as a valid target.

[japaric]

Would it be possible to not duplicate this list with the one below? Could the macro somehow use something like stringify! to build a vector, or could an iterator macro be used?

As @nodakai said, the mixture of hyphens and underscores makes it tricky.

I think "x86_64-w64-mingw32" is an alias for "x86_64-pc-windows-gnu" and should be included in the list as a valid target.

That's what the logic of this function seems to indicate. But, rustc --target=x86_64-w64-mingw32 ... returns error: Error loading target specification: Could not find specification for target "x86_64-w64-mingw32".

[brson]

I think "x86_64-w64-mingw32" is an alias for "x86_64-pc-windows-gnu" and should be included in the list as a valid target.

The former is deprecated and I don't think we should be promoting it.

[alexcrichton]

I agree with @brson that we shouldn't be handling aliases, and this also probably isn't the right place to discuss it regardless (e.g. an issue would be more appropriate).

@japaric sure it's trick but that doesn't mean it's not possible! I'd be personally much happier with something like:

load! {
    (x86_64_pc_windows_gnu, "x86_64-pc-windows-gnu"),
    // ...
}

It's basically just much easier if there doesn't need to exist a comment of "modify this other location as well" as they will invariably get out of sync.

[japaric]

sure it's trick but that doesn't mean it's not possible!

Well, I was thinking about a macro that didn't need to specify the triple twice in different formats (hyphenated and underscored).

I'd be personally much happier with something like:

Yeah, that looks less prone to errors. I'll look into it.

[alexcrichton]

This can in theory have some form of interaction with custom target specifications where we probe for foo.json in RUST_TARGET_PATH (both of which are... semi-stable). That being said I'm not sure I want a command like this to be probing around the filesystem for that kind of information.

I'm pretty ok with the option here, though. We may want to rename --print targets to something like --print supported-targets. Eventually we may have a "print all targets I have a standard library for" which may want to be called targets.

[alexcrichton]

cc @rust-lang/tools

[japaric]

... probe for foo.json in RUST_TARGET_PATH ...

Wait RUST_TARGET_PATH is a thing? TIL

That being said I'm not sure I want a command like this to be probing around the filesystem for that kind of information.

Yeah I don't think it should. The other --print commands don't do that kind of probing. Also it seems the command would have to look at all the *.json files and check that they are valid target specification files.

We may want to rename --print targets to something like --print supported-targets.

Happy to rename --print targets to --print supported-targets if the tools subteam decides so.

[alexcrichton]

Wait RUST_TARGET_PATH is a thing? TIL

That's ok, if you unlearn it right now I'd be fine with that.

[nagisa]

This should probably also print the target passed in to rust through --target=PATH.

[japaric]

Pushed two commits. The first one generates the TARGETS constant from the existing macro as @alexcrichton suggested. The second commit makes the rmake test simpler.

This should probably also print the target passed in to rust through --target=PATH.

This seems doable and makes sense, but I wasn't expecting it to come up in practice. @alexcrichton thoughts?

[japaric]

While copy pasting this code, I noticed these last two else-if branches are effectively unreachable (because of the let target = target.replace("-", "_"); a few lines above).

Not sure if I should fix them or just remove them. Probably the latter because @brson said these targets are deprecated.

[alexcrichton]

Ah for now I'd just leave out these targets entirely, we've generally tried to remove them as much as possible

[nrc]

Can we have target instead of targets? I think it is confusing to have --target but require the plural here (or just use something completely different like supported-targets.

[bors]

☔️ The latest upstream changes (presumably #31078) made this pull request unmergeable. Please resolve the merge conflicts.

[vi]

Can there be --target=help also doing the print?

[japaric]

Can there be --target=help also doing the print?

That's what I proposed on IRC because of the llc -march=mips -mcpu=help parallel. But @alexcrichton suggested --print targets; I think because we already use --print to query for other information. Also it's currently possible to create a target named "test", so --target=help could mean two different things.

[vi]

Alternatively, error message for unknown/malformed target like --target=qwerty may suggest using --print.

[alexcrichton]

Yeah right now --print is the way we currently have for printing various bits of information from the compiler. I do like the idea, though, of re-wording the error message for --target foo to suggest --print targets!

[alexcrichton]

Ok, the tools team had a chance to talk about this today during triage, and we all agreed that this is good to add, but none of us felt too too strongly about the name. Some possibilities were:

• --print target - matches the tense of --target
• --print targets - matches what's printed, a lot of targets
• --print target-list - also kinda matches what's printed?

I think that I may lean a bit in favor of target-list as we may have other things like target-support or target-with-std or something like that in the future. @japaric what do you think?

[japaric]

I like the sound of --print target-list, but I'm curious as to what --print target-support would do?

[alexcrichton]

Ah I was just thinking in terms of there being a difference between targets we can generate code for and targets we can generate things like rlibs/binaries for. The latter case would require a standard library and/or libcore, but as I write this down it sounds weird. Anyway target-list sounds good to me as well!

[japaric]

removed the deprecated mingw aliases, renamed print targets to print target-list, rebased and squashed. r? @alexcrichton

[alexcrichton]

Tagging as relnotes as we're basically dropping the old w64-mingw32 triples. I had no idea we were actually supporting them!

@bors: r+ 0bb4209

[bors]

⌛️ Testing commit 0bb4209 with merge 97842f5...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt