Tracking Issue for `--print=supported-crate-types`

[jieyouxu]

This is a tracking issue for the compiler print request --print=supported-crate-types.
This print request is currently unstable, gated behind -Zunstable-options.

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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Draft and accept an MCP: Add --print=supported-crate-types compiler-team#836
• Implement the print request as an unstable print option: Add unstable --print=supported-crate-types option #138641
• Adjust documentation (see instructions on rustc-dev-guide): Add unstable --print=supported-crate-types option #138641
• Stabilization PR (see instructions on rustc-dev-guide): TODO; after some baking

Unresolved Questions

• (Bikeshedding) Is supported-crate-types the best name for the print request?

Design decision history

None yet, since initial implementation.

Implementation history

• Add unstable --print=supported-crate-types option #138641

[weihanglo]

Just realized this won't help remove Cargo's hack on parsing error messages. Basically, Cargo is looking for something like these

___.wasm
lib___.rlib
___.wasm
lib___.a

in order to learn what file prefix/suffix a crate-type will emit.

Unless we have one more print option like --print prefix-suffix, cargo doesn't really benefit from this. That said, Cargo can o spawn an extra rustc invocation first to get supported crate-types, though it is costly and hurts startup time, and is alwasy a thing we want to avoid in Cargo in general.