`std::visit` is (arguably) cleaner code, but older versions of gcc
and clang (not very old; the ones packaged with Ubuntu 22.04 LTS)
compile them as tables of function pointers, instead of efficient
jump tables.
This allows us to control the order in which sections are iterated,
instead of it depending on the internals of `std::map`. (This order
is arbitrary, but should be deterministic regardless.)
It complains about *those* calls returning a dangling reference...
Unfortunately, GCC does not provide more information about what the
reference *is*. (It only mentions the temporary being destroyed at
the end of this *huge* expression.)
I am normally not one to just commit a thing that gets rid of a
warning if I can't explain why, but this eludes me.
Stubbing out the calls to only return a captured variable still
complains, which led me to test that the error wasn't stemming
from the `Visitor` itself... which it seems to?
But I don't see why a reference to the *visitor* should be kept...
Anyway, here is the obligatory part where I state my yearning for Rust :)
This still doesn't allow identical exported label constants.
That can be addressed when or if it's requested for a real use case.
Symbols only store one source filename + line number, so this
arbitrarily keeps the last read symbol as the reported one.
- Since we have style rules to include foo.hpp at the top of its
corresponding foo.cpp, this takes any headers included by foo.hpp
as being also guaranteed for foo.cpp.
- Use C-style <foo.h> instead of <cfoo>, since the latter only
guarantees putting symbols in the `std` namespace, which we are
not using for C functions (e.g. `printf` not `std::printf`).
- Remove now-unused `__PRETTY_FUNCTION__` reporting
