Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic with nested subcommands and tuple struct variants #76

Closed
Globidev opened this issue Feb 24, 2018 · 4 comments
Closed

Panic with nested subcommands and tuple struct variants #76

Globidev opened this issue Feb 24, 2018 · 4 comments
Labels
bug This is a BUG. The fix may be released in a patch version even if considered breaking

Comments

@Globidev
Copy link

Consider the following derived options:

#[derive(StructOpt, Debug)]
pub enum Options {
    #[structopt(name = "daemon")]
    Damon(DaemonCommand)
}

#[derive(StructOpt, Debug)]
pub enum DaemonCommand {
    #[structopt(name = "start")]
    Start,
    #[structopt(name = "stop")]
    Stop,
}

Running an incomplete ./app daemon will result in a panic

Traceback details
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
             at /checkout/src/libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::panicking::panic
             at /checkout/src/libcore/panicking.rs:51
  10: >::unwrap
             at /checkout/src/libcore/macros.rs:20
  11: ::from_clap
             at src/cli/mod.rs:31
  12: botd::cli::Options::from_subcommand
             at src/cli/mod.rs:21
  13: ::from_clap
             at src/cli/mod.rs:21
  14: structopt::StructOpt::from_args
             at /home/guillaume/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/structopt-0.2.3/src/lib.rs:368
  15: botd::main
             at src/main.rs:35
  16: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  17: std::panicking::try::do_call
             at /checkout/src/libstd/rt.rs:59
             at /checkout/src/libstd/panicking.rs:480
  18: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:101
  19: std::rt::lang_start_internal
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:365
             at /checkout/src/libstd/rt.rs:58
  20: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  21: main
  22: __libc_start_main
  23: _start

However, using a struct with a named field instead of a tuple struct for the subcommand doesn't result in a panic:

pub enum Options {
    #[structopt(name = "daemon")]
    Daemon {
        #[structopt(subcommand)]
        cmd: DaemonCommand
    },
}

This time, running the incomplete ./app daemon will correctly display the subcommand usage

@TeXitoi TeXitoi added the bug This is a BUG. The fix may be released in a patch version even if considered breaking label Feb 24, 2018
@TeXitoi
Copy link
Owner

TeXitoi commented Feb 24, 2018

I will publish a new release once #71 is merged (hopefully before monday).

@Globidev
Copy link
Author

Thanks a lot for the fast reaction!

@TeXitoi
Copy link
Owner

TeXitoi commented Feb 25, 2018

v0.2.4 published.

@Globidev
Copy link
Author

awesome 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This is a BUG. The fix may be released in a patch version even if considered breaking
Projects
None yet
Development

No branches or pull requests

2 participants