Tracking Issue for --print=supported-crate-types
#138640
Labels
A-print-requests
Area: print requests (`--print=...`)
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
jieyouxu
added
A-print-requests
1 task
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 23, 2025
…es, r=Urgau Add unstable `--print=supported-crate-types` option MCP: rust-lang/compiler-team#836 Tracking issue: rust-lang#138640 ### Test coverage Two tests: 1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated 2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently). ### Example output <details> <summary>For `x86_64-unknown-linux-gnu`</summary> Notice the presence of `{c,}dylib` and `proc-macro`: ``` bin cdylib dylib lib proc-macro rlib staticlib ``` </details> <details> <summary>For `wasm32-unknown-unknown`</summary> Notice the absence of `dylib` and `proc-macro`: ``` bin cdylib lib rlib staticlib ``` </details> <details> <summary>For `x86_64-unknown-linux-musl`</summary> Notice the absence of `{c,}dylib` but presence of `proc-macro`: ``` bin lib proc-macro rlib staticlib ``` </details> ### Documentation I added an entry in the unstable book's print request section to document this `supported-crate-types` print request. ### Unresolved questions - [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time. ### Stability This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time. ### Review remarks Best reviewed commit-by-commit. r? compiler
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this issue
Mar 23, 2025
…es, r=Urgau Add unstable `--print=supported-crate-types` option MCP: rust-lang/compiler-team#836 Tracking issue: rust-lang#138640 ### Test coverage Two tests: 1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated 2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently). ### Example output <details> <summary>For `x86_64-unknown-linux-gnu`</summary> Notice the presence of `{c,}dylib` and `proc-macro`: ``` bin cdylib dylib lib proc-macro rlib staticlib ``` </details> <details> <summary>For `wasm32-unknown-unknown`</summary> Notice the absence of `dylib` and `proc-macro`: ``` bin cdylib lib rlib staticlib ``` </details> <details> <summary>For `x86_64-unknown-linux-musl`</summary> Notice the absence of `{c,}dylib` but presence of `proc-macro`: ``` bin lib proc-macro rlib staticlib ``` </details> ### Documentation I added an entry in the unstable book's print request section to document this `supported-crate-types` print request. ### Unresolved questions - [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time. ### Stability This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time. ### Review remarks Best reviewed commit-by-commit. r? compiler
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 24, 2025
Rollup merge of rust-lang#138641 - jieyouxu:print-supported-crate-types, r=Urgau Add unstable `--print=supported-crate-types` option MCP: rust-lang/compiler-team#836 Tracking issue: rust-lang#138640 ### Test coverage Two tests: 1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated 2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently). ### Example output <details> <summary>For `x86_64-unknown-linux-gnu`</summary> Notice the presence of `{c,}dylib` and `proc-macro`: ``` bin cdylib dylib lib proc-macro rlib staticlib ``` </details> <details> <summary>For `wasm32-unknown-unknown`</summary> Notice the absence of `dylib` and `proc-macro`: ``` bin cdylib lib rlib staticlib ``` </details> <details> <summary>For `x86_64-unknown-linux-musl`</summary> Notice the absence of `{c,}dylib` but presence of `proc-macro`: ``` bin lib proc-macro rlib staticlib ``` </details> ### Documentation I added an entry in the unstable book's print request section to document this `supported-crate-types` print request. ### Unresolved questions - [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time. ### Stability This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time. ### Review remarks Best reviewed commit-by-commit. r? compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
--print=supported-crate-typescompiler-team#836--print=supported-crate-typesoption #138641--print=supported-crate-typesoption #138641Unresolved Questions
supported-crate-typesthe best name for the print request?Design decision history
None yet, since initial implementation.
Implementation history
--print=supported-crate-typesoption #138641The text was updated successfully, but these errors were encountered: