No way to disambiguate between a missing required param error and default help or version

[smaillet]

Consider the following app:

using System.CommandLine;

// Requires NuGet package: System.CommandLine 2.0.0-beta6.25358.103 (Latest prerelease)
namespace TestCommandLineParsing
{
    internal class Program
    {
        static void Main(string[] args)
        {
            var foo = new Option<string>("--foo")
            {
                Required = true,
            };

            var root = new RootCommand("Test app to illustrate issue")
            {
                foo
            };

            ParseResult result = root.Parse("--version");
            // AMBIGUITY: 
            //result.Action is System.CommandLine.VersionOption.VersionOptionAction (A private type so can't be tested)
            // result.Errors.Count == 1
            // Result.Errors[0].Message == "Option '--foo' is required."
        }
    }
}

As listed in the comments starting with AMBIGUITY there is no way to distinguish between a missing required parameter and the default version parameter. How can a consumer know if the default options are provided and should terminate ignoring the error reports? There's an inherent ambiguity on whether an error condition exists (because the required parm isn't provided) and the --version parameter. But THAT parameter will generate an error if it is used with any other options... (Effectively the validator for a required parameter should not add an error if --Version is applied of the validator for that shouldn't fail if it isn't solo)

[KalleOlaviNiemitalo]

#2644 added a CommandLineAction.ClearsParseErrors property. Does that suffice?

[smaillet]

If I understand the changes, yes. (Help would have the same problem). Though I share the reviewers concerns on this as it seems dangerous to treat that as a general solution. Seems like a large blunt hammer when a scalpel is all that is needed. Seems to me that something with the semantics of "clears required" is what is minimally needed. (That is, if that option is set, any option with the "required" property is treated as if it wasn't)

Qualification: The fix would only work if the order of processing that setting was guaranteed to occur AFTER the required option reports an error. It isn't clear to me that such a guarantee is, or even could be, made here.

[jonsequitur]

This sounds like a duplicate of #2628, which was fixed, but the fix hasn't gone out to nuget.org yet. You can confirm by using the latest builds from our CI feed here: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json

Seems like a large blunt hammer when a scalpel is all that is needed.

CommandLineAction.ClearsParseErrors was specifically added to fix this bug and remove the internal case-specific code that cleared parse errors when --help was used. So I think the --help scalpel was too precise. Once there's a second example, it implies the existence of others, which is why I advocated for a generalized approach.

Qualification: The fix would only work if the order of processing that setting was guaranteed to occur AFTER the required option reports an error. It isn't clear to me that such a guarantee is, or even could be, made here.

The clearing of parse errors happens after parsing is done, depending on which primary action was selected. I'm not aware of a bug but am happy to add test cases if there's something you think we might have missed.