- Notifications
You must be signed in to change notification settings - Fork412
Fixing issue #2392#2402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Fixing issue #2392#2402
Conversation
There were two problems addressed here.First, the call to Diagram was causing the second error to be added to the ParseResult.Errors collection. The diagram call, was being invoked by the debugger as part of the ParseResult.ToString() method. Causing the number of errors to change when inspecting a parse result.The second issue was the error message text. It was implying that the option expected a single value, when its arity allowed for more.
| { | ||
| /// <summary> | ||
| /// Interpolates values into a localized string similar toCommand '{0}' expects a single argument but {1} were provided. | ||
| /// Interpolates values into a localized string similar toOption '{0}' expects a single argument but {1} were provided. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Isn't this used by both options and commands?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This was to make the comment match the actual value that is getting returned. I believe the only usage is for options. I suspect this comment was wrong from a copy and paste error when we initially did the localization resources.
| if(!ArgumentArity.Validate(argumentResult,outvarerror)) | ||
| { | ||
| optionResult.AddError(error.ErrorMessage!); | ||
| argumentResult.AddError(error.ErrorMessage!); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I do not understand this change. If this is on options, I thought we got the errors from the option. Do we get them from the option's argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This was one of the key fixes, that was causing the diagram command to insert a duplicate error.
The process looks like this:
- During the Parse, this line was invoked and the error was added to the OptionResult.
- The AddError method adds the error into the SymbolResultTree, and keys it based on the symbol. However,ArgumentResult.AddError method has a special case for options, whereit will use the OptionResult if that is the parent. So in either case the error is added to the SymbolResultTree with the OptionResult as the key. However, in the case of theArgumentResult.AddError it also sets the _conversionResult. So the change here still sets the error on the OptionResult, but it also causes the
_conversionResultfield to be set. - When calling the Diagram (and likely this bug exists with other code paths as well), it will callArgumentResult.GetArgumentConversionResult. That method will call
ValidateAndConvertif the_conversionResultis null. CallingValidateAndConvertwill add an error to the result. This was the result of the second error being added. - Because Diagram was being invoked from theParseResult.ToString() it was being invoked whenever the debugger inspected a ParseResult. This was the reason for the un-usual behavior that you saw.
There were two problems addressed here.
First, the call to Diagram was causing the second error to be added to the ParseResult.Errors collection. The diagram call, was being invoked by the debugger as part of the ParseResult.ToString() method. Causing the number of errors to change when inspecting a parse result.
The second issue was the error message text. It was implying that the option expected a single value, when its arity allowed for more.