Arguments to tasks can be interpreted as cargo make options

[edmorley]

Describe The Bug

If hyphenated arguments are passed to a cargo make task, and those arguments happen to match a cargo make CLI option, then the arguments are consumed by cargo make rather than being passed to the task.

To Reproduce

# Makefile.toml
[tasks.testcase]
command = "echo"
args = ["@@split(CARGO_MAKE_TASK_ARGS, ;)"]

Then run cargo make testcase abc -p foo/bar/ def

Expected result:

Cargo make runs with the default profile ("development"), and outputs the string "abc -p foo/bar/ def".

Actual result:

Cargo make runs with the profile "foo/bar/", and outputs the string "abc def":

$ cargo make testcase abc -p foo/bar/ def
[cargo-make] INFO - cargo make 0.35.0
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: testcase
[cargo-make] INFO - Profile: foo/bar/
[cargo-make] INFO - Execute Command: "echo" "abc" "def"
abc def
[cargo-make] INFO - Build Done in 0.01 seconds.

This is surprising, since the usage text states:

USAGE:
    cargo make [FLAGS] [OPTIONS] [--] [ARGS]

...

ARGS:
    <TASK>            The task name to execute
    <TASK_ARGS>...    Task arguments which can be accessed in the task itself.

...that is, implies that anything after <TASK> must be <TASK_ARGS>... and not one of the earlier [FLAGS] [OPTIONS].

Adding -- resolves the issue(ie: cargo make testcase -- abc -p foo/bar/ def), however it is:

• additional characters to remember to type
• something newcomers to a project might not be aware of

In my case the task runs a subcommand that expects either a --path or -p argument. At the moment the only way I can think of to avoid people hitting this UX issue would be for me to write a manual step that validates CARGO_MAKE_PROFILE is an expected value (in our case "development" or "release").

Versions

$ cargo --version
cargo 1.54.0 (5ae8d74b3 2021-06-22)

$ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/emorley/.rustup

installed targets for active toolchain
--------------------------------------

x86_64-apple-darwin
x86_64-unknown-linux-musl

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.54.0 (a178d0322 2021-07-26)

[sagiegurari]

i'm using clap for cli arg handling. maybe you can investigate how to resolve it, but i think -- is kinda standard stuff in rust clis. not sure why

[sagiegurari]

@edmorley i have been looking here:
https://docs.rs/clap/2.33.3/clap/struct.Arg.html
and couldn't find a good way to do it. The code that uses clap to setup the cli is called cli.rs.
So at the moment this feels like a limitation of clap (or i just can't find a way to make it work) and i'm not planning to drop clap at the moment.
if this is something you want to investigate and push a PR if you find a solution, i would be happy to review and accept.