Add support for -- arguments

[jyn514]

I want to have arguments like this:

    cargo deadlinks [--dir <directory>] [options] [-- <CARGO_ARGS>]

Right now I have to call free() and manually parse the arguments. It would be nice to have built-in support for this. I'm imagining Arguments::dash_dash() -> (Vec<String>, Option<Vec<String>>) (or maybe just (Vec<String>, Vec<String>) for simplicity). It would behave like free() except that it parses out the -- for you.

[jyn514]

Right now I have to call free() and manually parse the arguments.

Actually, that doesn't work either because -- is treated as an option and free() gives an error.

error: unused arguments left: --, --document-private-items

[jyn514]

I can remove the -- with contains, but then I lose the difference between arguments before and after. I think to do this without support from pico_args I'd need Arguments::into_inner or something to give me the arguments exactly as they currently are. That has the downside that it no longer checks for unrecognized options, though.

[jyn514]

Oh! Instead, I can use Arguments::from_vec and handle -- before passing things to pico_args instead of after.

[jyn514]

I ended up with this:

    let mut args: Vec<_> = std::env::args_os().collect();
    args.remove(0);
    /* this bit is `deadlinks` specific
    if args.get(0).map_or(true, |arg| arg != "deadlinks") {
        return Err(Error::ArgumentParsingFailed { cause: "cargo-deadlinks should be run as `cargo deadlinks`".into() });
    }
    args.remove(0);
    */

    let cargo_args = if let Some(dash_dash) = args.iter().position(|arg| arg == "--") {
        let c = args.drain(dash_dash+1..).collect();
        args.pop();
        c
    } else {
        Vec::new()
    };

[RazrFalcon]

Yes, I guess from_vec is the best solution right now. Keep in mind, that pico-args is not a clap alternative. It's just a sugar over Vec<String>. You should treat it as a framework and not as a complete solution. Arguments parsing is an absurdly complex task and I intentionally don't plan to support anything beyond the current feature set.

Also, I have no idea how -- handled in other libraries and what edge-cases it can have.

I would say adding a usage example for -- is a better "fix".