There's some unnecessary code duplication in the demangler's parser. This refactors that, deploying boolean variable technology to avoid the duplication. These also happen to help adding module demangling (with an updated mangling scheme that I am working on).
1a) The grammar requires some lookahead concerning <template-args>. We may discover an <unscoped-name> is actually <unscoped-template-name> <template-args>. (When <unscoped-name> was a substitution, there must be a following <template-args>.) Refactor parseName to only have one code path looking for the 'I' indicating <template-args>.
1b) While there I altered the control flow to hold the result in a variable, rather than tail call. Made it easier to debug (and of course an optimizer will DTRT here anyway).
2a) An <unscoped-name> can have an St or StL prefix. No need for completely separate code paths handling the following unqualified-name though.
2b) Also no need to look for both 'St' and 'StL' separately. Look for 'St' and then conditionally swallow an 'L'.
- We get a similar issue as #1a when parsing a typeName. Here I just change the control flow slightly to bring the 'break' out to the end of the 'S' block and embed the early return inside an if. That's more in keeping with the code style.
- Although NFC, there's a new testcase as that's not covered by the existing demangler tests and is significant in the #1a case above.
Personally, I think the early returns are a bit easier to follow along with. WDYT?