./x.py c library/std not supported

[tesuji]

./x.py check library/std works but ./x.py c library/std doesn't.
The latter command give the following errors:

thread 'main' panicked at 'No option 'all-targets' defined', /home/lzutao/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.21/src/lib.rs:799:21

The commit I use is a1dfd24,
which is latest upstream commit at this time.

Meta

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/library/std/src/panicking.rs:483
   1: std::panicking::begin_panic_fmt
             at /rustc/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/library/std/src/panicking.rs:437
   2: getopts::Matches::opt_vals
             at /home/lzutao/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.21/src/lib.rs:799
   3: getopts::Matches::opt_present
             at /home/lzutao/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.21/src/lib.rs:813
   4: bootstrap::flags::Flags::parse
             at ./src/bootstrap/flags.rs:494
   5: bootstrap::config::Config::parse
             at ./src/bootstrap/config.rs:531
   6: bootstrap::main
             at ./src/bootstrap/bin/main.rs:14
   7: core::ops::function::FnOnce::call_once
             at /home/lzutao/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

cc @Mark-Simulacrum

@rustbot modify labels: A-rustbuild

[Mark-Simulacrum]

It is unclear to me -- did this work in the past? I wouldn't personally want it to be a thing but I guess maybe Cargo has already created the expectation for this alias?

[tesuji]

Yeah, it worked in the past. However I am fine with using check if that reduces maintenance burden.

[jyn514]

Mentoring instructions: Change

rust/src/bootstrap/flags.rs

Line 256 in f296163

"check" => {

to "check" | "c".

[jyn514]

It would be nice to have all those matches use Subcommand instead of strings, but that's a larger refactor.

[akoptelov]

It would be nice to have all those matches use Subcommand instead of strings, but that's a larger refactor.

Subcommands are created too late to be used here. But I think it should be possible to add a new enum SubcommandTerm { Build, Check, ... } that would be created as a subcommand arg is processed and used then in the rest of the code. @jyn514 is that what you meant?

[jyn514]

Hmm, I think there are existing Kinds you could use. I don't know if they're constructed early enough to be used here.

[LeSeulArtichaut]

Should we close this as #77624 got merged?