Option not being parsed correctly

[philippzagar]

The Argument Parser isn't able to parse an Option correctly in a very specific parameter setting (see example below). This may even result in wrongly parsed values.

ArgumentParser version: 1.0.1
Swift version: swift-driver version: 1.26.9 Apple Swift version 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6) Target: x86_64-apple-macosx12.0

Steps to Reproduce

The Argument Parser isn't able to parse an Option correctly if it is stated between a "normal" Argument and an Argument with the unconditionalRemaining setting.

Here an example:

struct ExampleCommand: ParsableCommand {
    @Argument(help: "Works as expected")
    var firstArg: String
    
    @Option(help: "Not recognized argument")
    var secondArg: String
    
    @Argument(parsing: .unconditionalRemaining, help:"Failure causing argument, especially the `unconditionalRemaining` option")
    var thirdArg: [String]
}

swift run ArgumentParserExample --help prints the following (for all tested swift-argument-parser versions, so v0.4.4 onwards):

OVERVIEW: Example Command that showcases bug in the swift-argument-parser

USAGE: example-command <first-arg> --second-arg <second-arg> [<third-arg> ...]

ARGUMENTS:
  <first-arg>             Works as expected 
  <third-arg>             Failure causing argument, especially the `unconditionalRemaining` option 

OPTIONS:
  --second-arg <second-arg>
                          Not recognized argument 
  --version               Show the version.
  -h, --help              Show help information.

A related run Command could look like the following: swift run ArgumentParserExample test1 --second-arg=test2 test3 --test4 -t

Repository containing example code reproducing the behavior described below. Try the different swift-argument-parser versions in the Package.swift file.

Expected behavior

One would expect that all stated CLI parameters are parsed correctly and that they can be accessed containing the correct values.
Especially, the secondArg parameter ( --second-arg ) is detected and parsed correctly.
Occurs correctly on v0.4.4 of the swift-argument-parser.

However, the thirdArg actually contains the --second-arg=test2 from the run CMD mentioned above. This shouldn't be the case, as only the secondArg should contain the correct value (test2), which it also does in this scenario.

Actual behavior

Starting with the swift-argument-parser v0.5 and up until the current v1.0.1 version, the parsing fails with the error message that the secondArg is missing (again, using the run CMD mentioned above):

Error: Missing expected argument '--second-arg <second-arg>'
Help:  --second-arg <second-arg>  Not recognized argument
Usage: example-command <first-arg> --second-arg <second-arg> [<third-arg> ...]
  See 'example-command --help' for more information.

Setting the name of the Option explicitly to second-arg (so --second-arg) within the initialization of the Option property wrapper doesn't change the behavior.

As soon as the unconditionalRemaining option for the last Argument is deleted, the parsing is done correctly, under the condition that the passed parameters after the --second-arg are not Option's on their own (so no --test4 or -t anymore). Same behavior as soon as the first Argument (so firstArg) is deleted.
As described in the example above, the secondArg parameter ( --second-arg ) isn't being detected correctly.

It seems to me that the .unconditionalRemaining option to a certain extent is responsible for this incorrect behavior. However, as mentioned above, if the firstArg is deleted, the parsing is done correctly, even with the .unconditionalRemaining option (even with correct values of the parsed parameters!).