Tracking Issue for cargo rustc --print=VAL

[ehuss]

Summary

Original issue: #8923
Implementation: #9002

cargo rustc --print=VAL forwards the --print flag to rustc in order to extract information from rustc. This runs rustc with the corresponding --print flag, and then immediately exits without compiling. Exposing this as a cargo flag allows cargo to inject the correct target and RUSTFLAGS based on the current configuration.

The primary use case is to run cargo rustc --print=cfg to get config values for the appropriate target and influenced by any other RUSTFLAGS.

Unresolved issues

(These aren't necessarily blockers, just random thoughts about the current design.)

• I think cfg is the only value that is worth printing. It is not clear from a UI perspective if it makes sense to expose the other values, since several will just fail or don't add anything different than running rustc directly. Forwarding the print value to rustc is more flexible and probably fine, though it seems like it could cause confusion.
• The intended use case of --print=cfg means anyone using it needs to implement a parser for the ad-hoc format. The original implementation parsed it and returned JSON, which might be easier to consume? There was some back-and-forth discussion on the PR about this, and possibly using a more general purpose subcommand (like cargo config) for "expose internal information". It might be worth considering that more.
• The behavior with multiple --target flags is a little strange.
• Profiles are ignored. This has historically caused confusion for people (for things like debug_assertions). However, all of cargo ignores profiles for the intended use case (--print=cfg). It's not clear what this should do.

Future extensions

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[volks73]

Thank you for creating this issue to track stabilization. I just wanted to briefly comment about a couple of the unresolved issues (not sure if I should be creating separate issues for each of these):

• The intended use case of --print=cfg means anyone using it needs to implement a parser for the ad-hoc format. The original implementation parsed it and returned JSON, which might be easier to consume? There was some back-and-forth discussion on the PR about this, and possibly using a more general purpose subcommand (like cargo config) for "expose internal information". It might be worth considering that more.

I have created the cargo-rustc-cfg crate so that others do not need to create a parser each time the output of the --print=cfg option is needed. This would avoid needing to create (and maintain) a JSON-based output format.

Please note, the release version (v0.2.0) was created and released prior to the existence of the cargo rustc --print cfg feature, but the version available in the main branch of the repository does utilize the new feature. I just haven't had a chance to release the new version, and I wasn't sure about releasing a "nightly only" version of the crate on crates.io and doing so before a feature was stabilized.

• The behavior with multiple --target flags is a little strange.

Could you expand on the strangeness of the behavior? Output for each specified --target is printed and delimited with an empty line. Granted, I only considered the --print=cfg variant and not other options for printing.

[ehuss]

Could you expand on the strangeness of the behavior?

Just that the blank line solution seems potentially brittle. It assumes the data will never have blank lines. Also, it may be difficult to correlate the output with the actual targets (let's say the targets are driven by a config file). Not big issues, and multiple targets is a very advanced use case, so it is unlikely to be used often.

[volks73]

Thank you for explanation and see the issue with using the blank lines to delimit the output for multiple targets. There appears to be two issues at play: (1) delimiting the output and (2) associating output with targets.

A --delimiter=<value> like option could be added to address (1) delimiting the output by changing the blank line to be a row of characters, such as --delimiter="-" would print 80 - characters. Or, simply decide on a non-blank line delimiter that would have a relatively low likelihood of existing in future output from the underlying rustc --print cfg command.

As for (2) associating output with targets, it might be possible to enforce the order specified at the CLI to the order that is printed. Currently, I believe there is no guarantees on the output order nor order for the incoming multiple --target options. The output is currently a "raw dump" of the rustc output, which does not include a line or key-value pair for the target tuple. A "title" line could be added that does include the tuple and maybe this can serve a dual purpose as the delimiter of output as well.

However, changing the output to a more structured format, such as JSON, resolves both issues with minimal changes to the CLI and implementation. The --print=<val> would need to be changed to --print-cfg to avoid complications with printing other values from rustc, as mentioned in the first bullet point, unless a generic JSON format can be designed for any output from rustc --print <val>.

Do you foresee rolling this into cargo config (#9301)? For example, a cargo config get rustc.cfg command?

[Gankra]

FWIW if this was stable it would let cargo subcommands run $CARGO rustc --print sysroot (or --print=target-libdir) (only reason I've ever seen someone use rustc --print, as someone who Doesn't Work On Rustc, But Does A Lot Of Crimes To It).

This would allow cargo subcommands to properly introspect the current toolchain and start asking questions like "hey is this non-host target actually installed, or should I error/ask-rustup-to-install-it-first".

...which is a thing cargo-dist tries to do, but doesn't do Properly Enough.

ofc that usecase could be addressed in a myriad of ways, but this is a good candidate solution that's generally useful. Alternatives would include:

• "a way to just ask cargo if a target is installed (or to list all installed targets)" (very specific, doesn't require tools to understand sysroots/targets)
• "a way to just ask cargo for the sysroot" (more generally useful, requires more legwork from tools)

[Gankra]

I'm loosely aware the "is a target installed" is a... More Complicated question then I'm implying, and am very happy to be told I should Actually be asking a more precise question of my toolchain, so if you want to xy-problem me even harder what I really want is to make it easier for rust developers to be able to say "hey current rust toolchain, make sure you've done everything you can to make it possible to build arm64 macos from intel macos (or linux-musl-static from linux-gnu), and also please let me know if the build Obviously Won't Work".

"Tell rustup to target add non-host targets we're trying to build" is a pretty good approximation of that, but it's uhhh unprincipled as heck.