Reenable testUsage() as testInvalidUsage() #8014
Conversation
I believe its expected for the argument `-halp` to show the help string in swift-argument-parser, as if there is a `-h` or `--help` anywhere in the arguments all other inputs are disregarded and the help string is shown. Instead use an invalid argument to drive the test and reenable it.
plemarquand
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
francescomikulis,
xedin,
dschaefer2,
shawnhyam,
bripeticca and
owenv
as code owners
|
@swift-ci test |
| @@ -48,10 +48,9 @@ final class PackageCommandTests: CommandsTestCase { | |||
| XCTAssertMatch(stdout, .contains("USAGE: swift package")) | |||
| } | |||
|
|
|||
| func testUsage() async throws { | |||
| throw XCTSkip("rdar://131126477") | |||
There was a problem hiding this comment.
Do we have this radar resolved then? I find it confusing that any option that starts with -h leads to this unexpected behavior. We should at least raise this on the SAP repo for them to resolve this first, especially as this is a regression from Swift Argument Parser 1.2.2.
There was a problem hiding this comment.
I think this is works as intended, but maybe @natecook1000 can chime in. If any argument resolves to a help flag it takes precedence and shows the help string.
Swift Argument Parser respects combined flags, so -halp is equivalent to -h -a -l -p. Short flags can be combined, and short flags must also be only one character, so -halp isn’t a valid as a single flag. Only short flags can be combined, so —help-foo won’t match —help.
There was a problem hiding this comment.
I'm surprised that's the default, given that both swiftc and clang stick to single dash options, and thus clang -fblocks is clearly not equivalent to clang -f -b -l -o -c -k -s.
There was a problem hiding this comment.
swiftc and clang also use options with -long-name so I wouldn't take them as amazing prior art. arg parser follows the pattern of ls -asl and git clean -Xdf where short names are combined.
There was a problem hiding this comment.
@MaxDesiatov @rauhul Any lingering concerns with this PR/behaviour?
There was a problem hiding this comment.
Even if swift build -halp is parsed the same as swift build -h -a -l -p and -h is a valid flag, I'd still expect an error message to be printed about invalid -a -l -p flags.
There was a problem hiding this comment.
I agree with @MaxDesiatov .
I also think swift-argument-parser test need to be augmented to cover this case, if they currently don't!
There was a problem hiding this comment.
After looking at the current swift package manager behaviour, I think I'm find with it.
Running swift build -halp and swift build -alhp both yield the help usage. That's ok.
Running swift build -alp yields an error.
❯ swift build -alp
error: Unknown option '-alp'. Did you mean '--vv'?
Usage: swift build <options>
See 'build -help' for more information.
The usage help should probably indicate See 'build --help for more informationorSee 'build -h' for more information. it currently has a single -beforehelp`.
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
| do { | ||
| _ = try await execute(["-halp"]) | ||
| _ = try await execute(["--xxx"]) |
There was a problem hiding this comment.
issue: Can we add a test, if they don't currently exist, that specified the behaviour when executing swift build -halp, swift build -alhp and swift build --help
There was a problem hiding this comment.
I think these tests should probably go in swift-argument-parser, since it handles the help arguments
There was a problem hiding this comment.
Similar tests should definitely be included in swift-argument-parser. However, from swift-package-manager perspective, it's an implementation details.
This is a large (ie: end-to-end) test, where the code under test is not visible. So from the tests's perspective, we don't know we are using swift-argument-parser, or maybe we will use a different argument parser in the future, which breaks the behaviour. As such, tests should be included in swift-package-manager that verify the expected behaviour as a software developer would use the command line. We should include large (ie: end-to-end) tests that cover the expected behaviour, or maybe at least describe the existing behaviour.
I believe its expected for the argument
-halpto show the help string in swift-argument-parser, as if there is a-hor--helpanywhere in the arguments all other inputs are disregarded and the help string is shown.Instead use an invalid argument to drive the test and reenable it.
Some lines in this file used tabs instead of spaces, so the diff is a bit nosier than it should be.