`dotnet test` string-backed, flag-style parameters require arguments incorrectly

Describe the bug

There are several forwarded parameters in the dotnet test command parser that are of type Option<string> but act like boolean flags. When set these forward along multiple string arguments to a child process. An example of this would be the --blame-crash-collect-always flag. This flag, and others like it, error in SDK 6.0.100 when called with no argument parameter, which isn’t in line with their intended use. These flags should be changed to not require an argument in order to work.

To Reproduce

In a project on the 6.0.100 SDK, run dotnet test --blame-crash-collect-always

Exceptions (if any)

Required argument missing for option: --blame-crash-collect-always

Further technical details

.NET SDK 6.0.100 release

There are two separate problems that I think we’ll run into:

• The current implementation doesn’t specify arity for these string options, and so System.CommandLine is defaulting to an arity of ExactlyOne for these string-typed parameters. This is what’s at the core of requiring the argument. This can be fixed in a few different ways:
  • Explicitly set arity in the constructors of these specific options to ZeroOrOne
  • Implicitly set arity by changing the type of the options to bool or bool? (because bools and any nullable value type are set to ZeroOrOne arity by the library)
• However, If you change the arity to ZeroOrOne, the interaction of the ForwardAsMany lambdas changes so that those values are always passed along. To change this the lambda need to be changed to check the value of the parsed argument being passed in, and if the value is false (for bool options), or null (for nullable options) then return Enumerable.Empty<string>() instead of the filled list.

[nohwnd]

You are right @baronfel I wrote full example here: https://github.com/dotnet/sdk/pull/26963#issuecomment-1210700289

Specifically for usage with PowerShell (which is common in our repos), it is the most natural thing to do is --no-restore:$NoRestore, which is broken with zero arity, and you would need to do ugly inline if.

[Tunduk]

Yeah, I forget about script scenario. Good point. Maybe we should add this info in the docs then