conflicting option names

[phlptp]

Take the configurability of an option into account when determining ambiguous names and conflicts.

[phlptp]

This will fix #1047
This will resolve #1048

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (e4ee3af) to head (a87a5da).
Report is 29 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##              main     #1049    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           17        17            
  Lines         4546      4583    +37     
  Branches         0       981   +981     
==========================================
+ Hits          4546      4583    +37     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[phlptp]

I made the changes in PR #1049. There were a few edge cases to work through that the fuzzer caught.
There is probably a bit more to do to take into account whether the subcommand or app itself is not configurable. That might require some additional thought. But for now this will resolve the --h issue and any other case where one of the options is not configurable, and hence wouldn't present an ambiguity in the config files.

[henryiii]

Oh, did this bug get fixed in 2.3.0? It used to be you had to put all lower case versions here.

[phlptp]

Didn't know there was a bug, but this resolved the pre-commit issue

[henryiii]

Haven't followed the fuzzer that closely, what does this do?

[phlptp]

Right now the fuzzer has a large number of options, and some limited mechanics to generate new ones. It processes the options making sure there is nothing that generates a seg fault or other bad condition. Then generates a config file from the results and reads that config file back in. This led to all kinds of inconsistencies that got fixed a few months ago. At some point I will make it so it checks to make sure the values read from the config file are actually the same as the original values, then I might consider submitting it to OSS-Fuzz. The current test just runs a quick_fuzz ~6 minutes and can catch some issues especially when changing some internal mechanics or other things. I will keep adding to it as I have time.

This particular test caught an issue with creating a positional option named config, which was newly allowed. This then triggered an error as it was trying to match with the config option which was not configurable, so had to make it so it checked for other options if some were not configurable.