This is a work in progress: its performance is unacceptably slow,
and it is obviously not a complete refactoring:
- The parser's semantic functions are still written for C-style
strings, taking `.c_str()` pointers instead of `std::string`
references (and using their methods, `<algorithm>`s, etc).
- Quoted string literals from the lexer still use our `String`
struct, which wraps around a fixed-size char array.
- Symbol values, macro arguments, and so forth are still pointers
to C-style strings with unclear ownership semantics (i.e. we
still have "leaks as a feature").
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.
Fixes `make develop` with Clang 17.
The warning only triggers on the auto-generated `yynerrs_` in `src/asm/parser.cpp`,
so it's not very useful to us right now.
- 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
