feat(cli): forward bash completions of third party subcommands

[titaniumtraveler]

What does this PR try to resolve?

Currently third party subcommands like cargo asm from cargo-show-asm don't
support shell completions, even when the corresponding cargo-<cmd> command does.
(I'm using cargo asm as example because it was the first subcommand that came
into mind that provides completions)

This PR fixes this for bash by using bash-completion's
_comp_command_offset function to generate these completions.
(Assuming these completions are available to bash-completion)

bash-completion is the package that is used by all major unix-like operating
systems to provide bash completions.

If the subcommand has no completion, that falls back to the default bash.
(That might not be exactly the same as _filedir, but should be correct anyway)

Note that _comp_command_offset is only supported since bash-completion >= 2.12.0,
which requires bash >= 4.2.0, which means that the default
bash version shipped with MacOs is not supported.
In that case we fall back to the previous behavior with _filedir.

How should we test and review this PR?

I'm not sure if there is any testing setup for shell completions for cargo.
I have just tested it manually by running these commands:
(In the working directory of this PR)

#!/usr/bin/env bash

# Install the subcommand
cargo install cargo-show-asm
# Load the completions for `cargo-asm`
eval "$(cargo-asm --bpaf-complete-style-bash)"
# (Re)source the new cargo completions
source src/etc/cargo.bashcomp.sh

and then tab-completing from cargo asm <TAB>.

Additional information

Further Possibilities

The same trick with _comp_command_offset could be used to get completions
for the command run with cargo run -- , assuming there is an easy way to get
the name of the binary that would be run. (And maybe something to dynamically (re)-load the completions.)

Prior Art

The zsh-completions already support the zsh-equivalent of this with

cargo/src/etc/_cargo

Lines 368 to 372 in 58cfd96

	# allow plugins to define their own functions
	if ! _call_function ret _cargo-${words[1]}; then
	# fallback on default completion for unknown commands
	_default && ret=0
	fi

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[titaniumtraveler]

Whoops. I did not notice that cargo.bashcomp.sh uses tabs not spaces ...

[epage]

Feel free to clean up your commit history.

Not looking too much at this atm as I'm not much of a bash or shell completion expert.

I did want to give you a heads up that we are working on replacing our shell completions (#14520) and so this change will be short-lived unless someone gets that working with the new stuff. I wonder if we should freeze development of our existing completions because of that.

[titaniumtraveler]

Feel free to clean up your commit history.

Kinda hoped that github supports git commit --fixup commits.

Not looking too much at this atm as I'm not much of a bash or shell completion expert.

I did want to give you a heads up that we are working on replacing our shell completions (#14520) and so this change will be short-lived unless someone gets that working with the new stuff. I wonder if we should freeze development of our existing completions because of that.

Yeah, I know about it.
I didn't know that native clap completions are already that far 😮
Considering how simple the change is I think it should be fine to include this change anyway.

[epage]

Kinda hoped that github supports git commit --fixup commits.

I wish

Considering how simple the change is I think it should be fine to include this change anyway.

And the regression in behavior when we switch? Or further blocking switching until this is fixed? Those are my concerns.

[titaniumtraveler]

Considering how simple the change is I think it should be fine to include this change anyway.

And the regression in behavior when we switch? Or further blocking switching until this is fixed? Those are my concerns.

Ahh. To be fair, since it is only shell completions and only for bash I would be fine with it.

I guess I will look into how that is handled in the native completions.

[weihanglo]

And the regression in behavior when we switch? Or further blocking switching until this is fixed? Those are my concerns.

I don't think a regression in completing custom subcommands will be a blocker. Also, Cargo's zsh completion has provided such a feature, so seems reasonable for bash to follow. Already added offsetting to custom subcommand as a task in native completion tracking issue. We could consider the support before stabilization.

[weihanglo]

Thanks for the contributions. It is nice!

[pacak]

I'm using cargo asm as example because it was the first subcommand that came
into mind that provides completions

FWIW if as long as we are talking about cargo-show-asm - you can invoke it via cargo-asm bypassing cargo and configure your shell accordingly.

[weihanglo]

FWIW if as long as we are talking about cargo-show-asm - you can invoke it via cargo-asm bypassing cargo and configure your shell accordingly.

That is true if you don't user any toolchain override, otherwise running cargo-asm directly might invoke cargo from a wrong toolchain because of missing $CARGO.

[titaniumtraveler]

I'm using cargo asm as example because it was the first subcommand that came
into mind that provides completions

FWIW if as long as we are talking about cargo-show-asm - you can invoke it via cargo-asm bypassing cargo and configure your shell accordingly.

I mean yeah. That is the whole reason this entire thing works.
But it still feels like a workaround. And if that is just not necessary that is definitely nicer.