Docopt causes nil value panic when called with no arguments.

[alexchandel]

The following minimal docopt program, which takes no parameters, panics when called without any arguments:

#![feature(plugin, core)]

extern crate "rustc-serialize" as rustc_serialize;
extern crate docopt;
#[plugin] #[no_link] extern crate docopt_macros;

docopt!(Args derive Debug, "
Usage: misc [options]

Options:
  -h, --help        Show this message.
");

fn main() {
    let _ = Args::docopt().decode().unwrap_or_else(|e| e.exit());
}

The panic message is:

thread '<main>' panicked at 'I don't know how to read into a nil value.', ~/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-0.6.33/src/lib.rs:944
An unknown error occurred

This should not happen, because it makes it impossible to have a program take no arguments and read from stdin, with '[-]'.

[BurntSushi]

Oh my. This is a very interesting bug! This code also triggers it, without the macro:

extern crate "rustc-serialize" as rustc_serialize;
extern crate docopt;

static USAGE: &'static str = "
Usage: misc [options]

Options:
  -h, --help        Show this message.
";

#[derive(RustcDecodable)]
struct Args {
    pub flag_help: bool,
}

fn main() {
    let _ = docopt::Docopt::new(USAGE).and_then(|d| d.decode())
                                      .unwrap_or_else(|e| e.exit());
}

Notice anything funny? What is the type of _ in that expression? I don't think this program should compile!

If you change the let to:

    let _: Args = docopt::Docopt::new(USAGE).and_then(|d| d.decode())
                                            .unwrap_or_else(|e| e.exit());

Then all is well.

Somehow, in the absence of Args, Rust infers the type to be... nil? Huh? Very strange.

@alexchandel In your case, you should use:

let _: Args = Args::docopt().decode().unwrap_or_else(|e| e.exit());

and it should work.

This is a terrible failure mode though. I'm not sure how to improve it. @alexcrichton Does this look like a bug in rustc or is it intended behavior?

[alexcrichton]

Whoa, this is surprising! I've opened an issue on this: rust-lang/rust#21878

[BurntSushi]

I'm going to close this because it's being tracked upstream in Rust proper. I'm not sure there's much we can do here.

[caipre]

@BurntSushi : The corresponding issue was closed upstream but is still relevant here (type inference fails). Would you accept a PR adding a comment that specifying the type is necessary to avoid this panic?