- Single unified routine for erroring out or handling missing dependencies
- Single three-state enum instead of two Booleans for missing dependencies
(this causes `-MC` to imply `-MG` instead of needing `-MG -MC`)
- Functions than can miss included files return a Boolean for whether the
parser should `YYACCEPT` and exit
* Remove `err` and `warn`, keep `errx` and `warnx`, using them in RGBGFX too
* Separate RGBGFX and RGBLINK warnings/errors from main options
* Separate `report` function into `error` and `fatal` messages
* Implicit newlines for most RGBASM errors
Identify files by (device, inode), not by path, so that symlinks,
relative paths, case-insensitive paths, or other edge cases
do not result in double includes.
Part of that condition's purpose is to ensure that we read the correct
lexer state; but it's possible now for the fstack to be non-empty
*before* the lexer state is registered, i.e. if there is an error
in the function that registers it.
This causes a NULL pointer deref.
* Implement custom generic tagged union `Either`
This should be more efficient than `std::variant`, while still
keeping runtime safety as it `assert`s when `get`ting values.
* Use `Either` for RPN expressions
* Use `Either` for file stack node data
* Use `Either` for `File` buffer
* Use `Either` for `STRFMT` args
* Use `Either` for RGBLINK symbol values
* Support an equivalent of `std::monostate` for `Either`
* Use `Either` for lexer tokens
* Use `Either` for symbol values
* Use `Either` for lexer mmap/buffer state
This way, if a child context initializes `\@`, the parent won't
reset it. And if the child context did not initialize `\@`,
then resetting it would be redundant.
`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.
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 :)