doxygen: fix keywords leaking into return type

[marzer]

Hola! I have done some work on doxygen.py/parse_func() to fix #225 and #226 by unifying the various ways the function handles the cases were doxygen leaks some keywords into the return type. It now should work regardless of the order they leak in and/or if they appear at the beginning or end of the type, as well as being more robust in the face of future Doxygen ~fuckups~ regressions. Brute force, yo.

Also did some drive-by fixes:

• Added support for C++20's consteval (since mimicking the way constexpr was handled for functions seemed easy enough)
• Fixed a typo in CONTRIBUTING.rst

I've updated the doxygen tests, too. When I run them there are a number of test failures completely unrelated to functions (inline namespaces and such), but they appar to be known issues with Doxygen 1.9. They pass when I select only the ones that are relevant to my changes:

python -m unittest discover -p test_cpp.py
python -m unittest discover -p test_compound.py

[marzer]

Oh, interesting, looks like ~there might be some other test HTML I've forgotten to update~ I'm a dumbass. Hold please.

[codecov[bot]]

Codecov Report

Merging #228 (89bffa9) into master (6f5c7d5) will increase coverage by 0.00%. The diff coverage is 93.10%.

@@           Coverage Diff           @@
##           master     #228   +/-   ##
=======================================
  Coverage   98.15%   98.16%           
=======================================
  Files          27       27           
  Lines        6951     6963   +12     
  Branches       49       49           
=======================================
+ Hits         6823     6835   +12     
  Misses        128      128           

Impacted Files	Coverage Δ
documentation/doxygen.py	99.04% <93.10%> (+<0.01%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 6f5c7d5...89bffa9. Read the comment docs.

[marzer]

There we are. Should be good now.

[mosra]

Rebased and merged as 2add9e0e7b18a5c7a9a6e1cfcfb8b303cadffc21, thanks a lot for your patience :)

[marzer]

Rebased and merged as 2add9e0, thanks a lot for your patience :)

No worries, happy to help improve the lib 😄

As an aside/out of curiousity: what's the deal with PR merges on this repo? They're closed but then still somehow merged in anyways. Some git/tooling shenanigans?

[mosra]

I pull the branch locally and rebase it on top of master first, to avoid a merge commit.

Historically GitHub didn't have UI to do that for me without squashing all commits together (maybe it does now? never actually bothered checking, GitLab used to have that as a paid feature), plus usually I also do a final pass over the changes locally before finally pushing them to master. To make the PR appear as merged, I'd need to push the rebased commits back to your repo, and for obvious reasons ("what the hell happened to my fork while I was not looking??") I'm not doing that :D

[crisluengo]

There is a "Rebase and merge" option.