apple / swift-argument-parser

Straightforward, type-safe argument parsing for Swift
Apache License 2.0
3.31k stars 311 forks source link

Usage generated by built-in help flag prepends names of `OptionGroup`s to command stack if all arguments are optional #578

Open YourMJK opened 1 year ago

YourMJK commented 1 year ago

The usage generated by the built-in help flag has the name of the type of all @OptionGroup members prepended to the command stack if all options and arguments are optional (i.e. have a default value) and thus differs from the usage in e.g. ParsableCommand.helpMessage().

ArgumentParser version: 1.0.01.2.2 & main Swift version: 1.62.15 Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)

Checklist

Steps to Reproduce

Expected behavior

The usage string that is printed as part of the help message is the same as the usage printed when running it with no arguments and the same as returned by Test.helpMessage().

In this case:
USAGE: test [--num <num>] [<arg>]

Actual behavior

The usage string that is printed as part of the help message contains the name of the type of all @OptionGroup members before the actual command name.

The first line printed when executing the binary with only "--help" as an argument is: USAGE: group test [--num <num>] [<arg>]

and thus differs from the other methods of getting the usage which are all as expected.

If we change our ParsableCommand struct to have at least one non-optional argument by removing one of the default values, the usage returned by the built-in help flag is fixed.
For example, with:

struct Test: ParsableCommand {
    struct Group: ParsableCommand {
        @Option
        var num: Int = 0
    }

    @OptionGroup
    var options: Group

    @Argument
    var arg: String// = ""
}

the help flag correctly produces:
USAGE: test [--num <num>] <arg>
again.

YourMJK commented 1 year ago

Seems like this issue doesn't occur when you use ParsableArguments instead of ParsableCommand for the @OptionGroup's type.