[MISC] Allow options for subcommands

[eseiler]

Follow-up of #238

Main Problem

The subcommand is determined by just checking whether any argument matches a subcommand.
To allow options for the top-level-parser, we need to know whether a potential subcommand is actually an option value.
E.g.,

// raptor build is a subcommand
raptor -o build

Currently, it would use build as subcommand and then fail on parse() of the top-level-parser.
At this point of parsing, we don't know whether -o is an option or flag, so just checking for - is not enough.

My first intuition is that the format_parse needs to know about (and) handle the subcommands. Which would also mean that it needs a pointer to the parent.
However, special formats also must know to which command they apply.

Since format_parse has functions to check if an option or flag is set, those might be reused.

Test cases

Test case 1

// raptor has option `-o`
// raptor-build has option `-o`
raptor build -o foo
// `-o` belongs to build

Test case 2

// raptor has option `-o`
// raptor-build has option `-o`
raptor -o build build -o build
// first `-o` belongs to raptor, second to raptor-build

Test case 3

// raptor has option `-o`
// raptor-build has option `-o`
raptor -o build buidl -o build
// Wrong subcommand!

Test case 4

// raptor has option `-o`
// raptor-build has option `-o`
raptor -o=build build -o=build
// first `-o` belongs to raptor, second to raptor-build

Test case 5

// raptor has flags `-{b,u,i,l,d}`
// raptor-build has option `-o`
raptor -build build -o build
// `-build` are flags for raptor, `-o build` an option for raptor-build

Test case 6

// raptor has option `-o`
// raptor-build has option `-o`
raptor -o build // raptor short-help
raptor -o build --help // raptor full-help
raptor -o build build // raptor-build short-help
raptor -o build build --help // raptor-build full-help
raptor build // raptor-build short-help
raptor build --help // raptor-build full-help
raptor -o build build -o build --help // raptor-build full-help

Test case 7

// --option is an option
// What should happen?
raptor --option --help

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
sharg-parser	✅ Ready (Inspect)	Visit Preview	Mar 1, 2024 9:43pm

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.10%. Comparing base (01f848e) to head (d44f6a1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #244      +/-   ##
==========================================
- Coverage   95.13%   95.10%   -0.04%     
==========================================
  Files          18       18              
  Lines        1728     1735       +7     
==========================================
+ Hits         1644     1650       +6     
- Misses         84       85       +1     

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

[SGSSGene]

I see two things:

1. std::vector<std::string> options is used as a set, so maybe std::unordered_set<std::string> is the appropriate data structure.
2. I personally prefer 'unknown subcommand' over 'misspelled subcommand'

[eseiler]

I see two things:

1. std::vector<std::string> options is used as a set, so maybe std::unordered_set<std::string> is the appropriate data structure.
2. I personally prefer 'unknown subcommand' over 'misspelled subcommand'

Agreed.

I ended up refactoring verify_identifiers while trying to not store options in both used_ids and options. I also ended up that this would be a follow-up if at all :D