cargo b -Z help != cargo build -Z help

[gilescope]

b should be a shortcode for build and nothing different should happen but I'm seeing differences:

cargo build -Z help
**snip correct output**

but for b I get:

cargo b -Z help
error: unknown `-Z` flag specified: help

cargo b builds fine so I think we need to re-examine how we're implementing these shortcodes.

While I'm here it would be great if there was a special case put in to point people at the -Z help flag. I can never quite remember how to get to it. E.g.

cargo build -Z
error: The argument '-Z <FLAG>...' requires a value but none was supplied

USAGE:
    cargo build -Z <FLAG>...

For more information try --help

if we could add a special case like the following it would help a lot:

 (or for a list of available -Z flags use `-Z help`)

[heisen-li]

Oh, I'm so unlucky, I'm off work, otherwise I'd run more tests. I wonder if the shorthands of other logos also have this problem.

[heisen-li]

I did a simple test.

cargo build(b)/check(c)/doc(d)run(r)/test(t) -Z help

The above situation seems to happen.
Is this supposed to happen? Or was there an accident?

[ehuss]

No, it isn't intentional. I'm not sure how easy it will be to fix. The issue is that -Z help is checked very early here. However, since b is not a true clap alias, the initial argument parsing doesn't parse the -Z flag (because clap doesn't parse arguments for unknown subcommands). The alias gets expanded to the true build subcommand here, but it doesn't check the -Z flag again, so it fails. I can imagine lots of different ways to approach fixing this, but I don't really know which would be the least intrusive.

[heisen-li]

@rustbot claim