rust-lang/compiler-team (original) (raw)

Proposal

Summary

Add an unstable --print=supported-crate-types rustc flag which outputs a newline-delimited list of crate types that are supported by a given target:

$ rustc --print=supported-crate-types --target=wasm32-unknown-unknown
rlib
staticlib
[...]

Alternative json format

Alternatively, we could also introduce an unstable --print-json=supported-crate-types which outputs a line of JSON that's more friendly for tooling instead of newline-delimited plain text.

$ rustc --print-json=supported-crate-types --target=wasm32-unknown-unknown
{ "print_kind": supported_crate_types", "target": "wasm32-unknown-unknown", "supported_crate_types": ["rlib", ...] }

Primary motivation

compiletest relies on --print=all-target-specs-json and --print=cfg to collect target info for its various {ignore,only,needs} directives. However, what crate types are supported by a given target is not contained within these two --print flags, and trying to maintain such supported crate types list separately in compiletest is fragile and easily becomes outdated.

Aside: using --print=supported-crate-types to add a //@ needs-crate-types: ... directive

Currently, test writers have to manually maintain ignore-$targets to skip targets.

• An example of this is dylib being unsupported by default on wasm targets.
• Another motivation of this is supporting dynamic linking (by default) != supporting {c,}dylib by default. E.g. musl targets which currently doesn't support dylibs by default because musl libc is currently statically linked, but this may change in the future if someone works on it, in which case ignore-musl is very easy to forget to update.

See compiletest: add a proper supports-crate-type: xxx directive #132309.

Example test that would benefit from a dedicated supports-crate-type directive versus manually maintaining a list of target ignore-*s: rust-lang/rust#134906.

Third-party tools like cargo-semver-checks may also benefit from being able to obtain this information directly.

Secondary motivation

cargo currently does target supported crate types detection by trying to build a $crate_type for the target, then read the unsupported crate type warning:

dropping unsupported crate type `{$crate_type}` for target `{$target_triple}`

See rust-lang/cargo#15036, which works around rust-lang/rust#116626.

Note that cargo may or may not benefit from --print=supported-crate-types even if this flag is added due to the cost of an extra rustc invocation.

Stability guarantees of the flag and its output

Note that this proposal is to add --print=supported-crate-types or --print-json=supported-crate-types as an unstable flag guarded behind -Zunstable-options. Proposing this for stabilization should go through the usual process. This section tries to describe what kind of stability (or explicit lack thereof) we may consider for the form and output of this flag when and if it comes to stabilizing this --print/--print-json option:

What would be stable:

• The flag itself: rustc --print=supported-crate-types or --print-json=supported-crate-types
• The shape of the crate types list, that is, supported crate types are newline-delimited for the plain-text version, or the shape of the json (subject to experimentation).

What would be perma-unstable:

• The exact crate types which are supported by a given target, including Tier 1/2 targets.
  • This is to permit adding/renaming/removing/deprecating crate types that are supported by a target, without accidentally locking us into stability guarantees re. what crate types are supported by a target.

Prior discussions

https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Proposal.3A.20.60--print.3Dsupported-crate-types.60

Mentors or Reviewers

N/A, I plan to implement this myself, standard compiler reviews apply.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.