Issue992 - re-parse values using correct type for add_options from flow_callbacks. #999
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
close #992
repackaging of stuff from work with @mshak2 on wis2... there were enough patches that it made sense to deal with this separately. The problem is explained in #992. when options were declared in callbacks, and their type was not list (the default) they would be parse as lists anyways, because parsing encountered the type declarations after already having parsed the values.
At the end of option processing... there is already logic to re-examine "undeclared" variables. The existing logic removes variables that were declared in callbacks from the undeclared lists so that we don't generate bogus "undeclared" messages. These patches add, that when you find a declared option... re-parse the value to have it match the type declared for the option.
The string parsing for set values, was done weirdly with code in two places, Since we now needed it in a third place, the original two were consolidated into a set value parsing routine, and call it from all three places.