Open
Description
Not necessarily for this PR, but I think we should settle on a consistent way of listing out sets of alternatives like this across our options. We currently have
- Exhaustively listed in command (
--crate-type [bin|lib|rlib|...]
)- Listed in help in parentheses (
INFO may be one of (all-target-specs-json|calling-conventions|...)
)- Listed in help as a textual list (
The KIND can be one of dependency, crate, native, framework, or all (the default).
)
With this being a fourth potential layout
Originally posted by @clubby789 in #140077 (comment)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
clubby789 commentedon Apr 21, 2025
For options where output is going to be lengthier (emit, print), perhaps we could explain only the syntax, and leave a link to the relevant reference entry? Alternatively, we could gate full explanations behind
--verbose
(not sure if this would require refactoring?)xizheyin commentedon Apr 21, 2025
There are indeed some inconsistency.
I researched some command line help messages and found the following rules:
<option1|option2|...>
indicate required parameters.[option1|option2|...]
is a common way of representing options which is not nessary.* item - description
-Branch list with star is the list of options for which a detailed description appliesSo I think there needs to be many places in the current help message where changing
[]
and()
to<>
would be clearer. (This also avoids[]
lists conflicting withTYPE[=FILE]
)Reference:
xizheyin commentedon Apr 21, 2025
That is reasonable to me.
Rollup merge of rust-lang#140152 - xizheyin:issue-140102, r=jieyouxu
Unrolled build for rust-lang#140152