Tracking issue to stabilize --print target-spec-json

[cardoe]

This issue is meant to track the stabilization of the rustc flag --print target-spec-json which will output the currently selected target as a valid target spec that can be loaded with --target for only the same version of the compiler that generated it. This explicitly avoids saying that target specs are stable but instead intends to assist target spec users to know that their configuration will work with the current version of the compiler.

ref #38061

[Mark-Simulacrum]

We currently don't even seem to know about this unless -Zunstable-options is passed, which make it incredibly hard to discover. I think there's a note somewhere about that, but I don't know quite where. Just noting here.

[zackmdavis]

don't even seem to know about this unless -Zunstable-options is passed, which make it incredibly hard to discover

(probably bug #41683, fixed in #43260)

[cardoe]

ping on possibly stabilizing this.

[nrc]

We discussed this at the dev-tools meeting today. The general feeling was that while this is a fine feature with no obvious problems, there is not a lot of pressure to stabilise, and that given that target specs are unstable, it is probably best not to rush into that.

@cardoe Is there motivation from your end to have this on stable, rather than nightly-only?

[cardoe]

Well I'd use it to generate the specs for Yocto. I've discussed it on other tickets but I can't use the built in targets because of the need for custom sysroots (e.g. the linked Cargo issue) Yocto has a host environment, which is effectively built for the running OS and then the target environment that things are being built for. In some cases they can both be x86_64 machines but they target different libc's and optimizations (e.g. avx on the host but not on the embedded x86_64 target).

So I have to hand craft spec files and detect whenever something changes upstream and adjust them. But if I had this flag it could programmatically be done by making the necessary linker/compiler change to an existing target. It'd basically make it that I'd get newer Rust versions out to Yocto consumers quicker.

I'm not sure if others would use it but that's my personal motivation.

[boris-kolpackov]

I would also like to see this stabilized. My use-case is support for Rust in a build system (build2) where I need to know the compiler's target. AFAIK, this option is the only way to obtain this information (but please correct me if I am wrong).

Could we perhaps stabilize the output as "subject to change" in a sense that new values can be added and existing values removed only guaranteeing that the meaning of an existing value does not change? I think most consumers of this output will be perfectly capable of dealing with this.

While at it, I would also suggest adding values printed with --version -v to this output. Currently, to obtain the compiler version one must parse the --version output which is likely to get localized in the future. As an additional benefit, this will allow getting both the version and the target with a single invocation.

[pnkfelix]

We discussed this in today's T-compiler backlog bonanza meeting

The takeaways were:

• We do have precedent for generating output from stable compilers that is subject to change, namely --emit mir and --emit llvm-ir.
• We think there may be coupling between the decision on this issue and the decision on De-stabilize target spec JSON  #71009
• We may want to discourage people from making tools that rely on this output. There was a specific suggestion that we add a header to the output of --print target-spec-json that makes it invalid JSON and warns people not to depend on the output format. (We also might want to rename the parameter itself to just target-spec as well.)

So, overall, it seems like there's motivation to stabilize something here, but we would need the above questions resolved before we could move forward on that.

@rustbot label +S-tracking-design-concerns

[boris-kolpackov]

BTW, if anyone is banging their head against this (i.e., needing to know the compiler's target but only able to get it if using the nightly Rust compiler), there is the RUSTC_BOOTSTRAP=1 environment variable hack that would allow you to use this option even on the stable Rust compiler (I know the use of this variable is strongly discouraged, but you have to do what you have to do when there is no other option).

[boris-kolpackov]

In the meantime, perhaps we can consider adding the target triplet (which I believe is what the majority of use-cases are after) to the rustc -vV output, next to the host triplet? I've created an issue for this #105588.