Fix zsh/bash completions for arguments in option groups with a custom completion

[CraigSiemens]

Issue

• Fixes Zsh completion missing for arguments in an option group with custom completion #646

Description

The issue

It was caused by a mismatch in the completion scripts and the custom completion parsing. This is following the example from the issue above.

• The completion scripts contained the name of the argument

  ':arg-in-option-group:{_custom_completion $_completion_example_commandname ---completion -- argInOptionGroup $words}'

• The parsing of the completion command failed to find the argument using ArgumentSet.firstPositional(named:).
  This was caused by the function creating an InputKey with just a name and comparing to keys in the set that have their name and path set.

  In other words

  InputKey(name: "argInOptionGroup", parent: nil) != InputKey(name: "argInOptionGroup", parent: .init(named: "optionGroup", parent: nil))

There's also another issue that would occur when a command and an option group each contain an argument with the same name. In that case the completion would always match the first one in the ArgumentSet even if the user is trying to get completions for the second argument.

The fix

The completions scripts were updated to contain the full path of the argument instead of just the name. Then the completions parser can create an InputKey that will exactly match one in the ArgumentSet.

To avoid having the logic spread out, an extension was added to InputKey to get the fullPathString from a key and an init to create an InputKey from a fullPathString.

I also updated the bash completion script to use ArgumentDefinition.customCompletionCall(_:) that the zsh script was already using to deduplicate the logic.

Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary (wasn't necessary)

[natecook1000]

Looks good, thanks for working on this! One nit, then we should be good to merge.

Have you had a chance to see if this behavior occurs with fish completions as well?

[CraigSiemens]

Let's use the stdlib method here instead of Foundation's:

👍 That's been pushed to the branch.

Have you had a chance to see if this behavior occurs with fish completions as well?

From what I can tell, it appears that completions for arguments aren't being generated currently for fish.

This is returning nil if the ArgumentDefinition.names is empty.
https://github.com/apple/swift-argument-parser/blob/5be327c/Sources/ArgumentParser/Completions/FishCompletionsGenerator.swift#L62-L64

names will always be empty for positional arguments.
https://github.com/apple/swift-argument-parser/blob/5be327c/Sources/ArgumentParser/Parsing/ArgumentDefinition.swift#L109-L114

It'll take me some more time see if there's a reason for the condition in the guard and what the solution would be.

[CraigSiemens]

I've added a commit that adds the arguments to the fish completions. I tried implementing the logic to follow the bash/zsh implementations to control which arguments are shown/hidden.

[CraigSiemens]

The completions now include the --version flag like the bash/zsh commands.

[CraigSiemens]

The changes seems to have also fixed another bug where it could suggest help following subcommands when it isn't a valid subcommand.

[natecook1000]

@swift-ci Please test