more flexible error reporting for SymbolResult

[adamsitnik]

I've removed SymbolResult.ErrorMessage as it did not allow for providing multiple errors for single result and introduced SymbolResult.ReportError (name can be changed, I don't have strong preferences about it).

SymbolResult.ReportError adds a new error to the list of errors (so multiple errors per result are supported) and in case of ArgumentResult also sets ArgumentConversionResult (perf, simplicity) and encapsulates the fact that Option.Argument is internal and for Arguments owned by Option sets the parent to OptionResult rather than ArgumentResult

I also did a lot of refactoring related to ArgumentConversionResult, I am going to add comments explaining why.

[adamsitnik]

at this moment we know that it's a failure

[jonsequitur]

Very nice. As long as we don't later allow clearing of the errors.

[jonsequitur]

Was a test added to pin the expected behavior when ReportError is called more than once?

[adamsitnik]

previously this method was implemented in ParseResultVisitor, I've moved it here and implemented in a way it does not require an allocation of temporary list

command-line-api/src/System.CommandLine/Parsing/ParseResultVisitor.cs

Lines 251 to 295 in 6524142

	var passedOnTokensCount = previousArgumentResult.PassedOnTokens?.Count;
	if (passedOnTokensCount > 0)
	{
	ShiftPassedOnTokensToNextResult(previousArgumentResult, argumentResults[i], passedOnTokensCount);
	}
	}
	// If this is the current last result but there are more arguments, see if we can shift tokens to the next argument
	if (commandArgumentResultCount == i)
	{
	var nextArgument = arguments[i];
	var nextArgumentResult = new ArgumentResult(
	nextArgument,
	_symbolResultTree,
	_innermostCommandResult);
	var previousArgumentResult = argumentResults[i - 1];
	var passedOnTokensCount = _innermostCommandResult.Tokens.Count;
	ShiftPassedOnTokensToNextResult(previousArgumentResult, nextArgumentResult, passedOnTokensCount);
	argumentResults.Add(nextArgumentResult);
	if (previousArgumentResult.Parent is CommandResult)
	{
	AddToResult(nextArgumentResult);
	}
	_symbolResultTree.TryAdd(nextArgumentResult.Argument, nextArgumentResult);
	}
	if (commandArgumentResultCount >= argumentResults.Count)
	{
	var argumentResult = argumentResults[i];
	ValidateAndConvertArgumentResult(argumentResult);
	if (argumentResult.PassedOnTokens is { } &&
	i == arguments.Count - 1)
	{
	_unmatchedTokens ??= new List<Token>();
	_unmatchedTokens.AddRange(argumentResult.PassedOnTokens);
	}

[adamsitnik]

this method is now responsible for entire validation. The problem is that it can be called by not only the ParseResultVisitor but also custom parsers and validator which can do things like ArgumentResult.GetDefaultValue(). For the latter case I've added potentialRecursion argument to ensure we don't have endless recursion (validator->getvalue->validator)

[jonsequitur]

The name potentialRecursion is a little unclear to me. Is this saying whether to allow recursion?

[adamsitnik]

I've moved this logic from the visitor and re-wrote in a way that we don't iterate over every argument more than once (previously we were setting the default values and then validating).

[adamsitnik]

@jonsequitur the PR is ready for review. I hope that you like the refactoring I've made. The side-effects of the refactor is improved performance. For the simple use case Jan is always using it's 1-3% for cold startup time scenario (start a new process, parse the args, print and exit: jkotas/commandline-perf#2), for micro-benchmark it's 20% faster (less important, as it's warm), but the allocations has reduced nicely

[KalleOlaviNiemitalo]

This required changes in pretty much all of my custom parsers. They were easy to implement, though.