* 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 line was missing; in its absence, as soon as the array reallocs,
all registered symbol pointers are invalidated, leading to a crash
(e.g. when generating a sym file).
Made the reallocation check into a hard error, too.
Since fileSymbols gets registered with each section, we would have to
change that, and then it cascades throughout all of RGBLINK.
This will be handled correctly in the Rust port.
Passing a count parameter to the vector constructor does not reserve
count elements but instead fills the vector with count elements.
This caused the endianness check to fail first because the first 256
characters were null bytes.
- FIX: `Label & const` was not actually doing the `& const` masking
(fixes#1446)
- ADD: `LOW(Label)` can be constant if `Label` is aligned to 8 or more bits
(resolves#1444)
- ADD: `!expr` can be constant 0 if `expr` has any non-zero bits
(resolves#1447)
- `LOW()` and `HIGH()` have their own RPN operator values
(resolves#1445)
The change to RPN values means that the object file version was incremented.
This also refactors unary operators and functions, combining their
evaluation similarly to binary ones.
`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 :)
Rangi42
Sylvie
Rangi42
ISSOtm
Ruben Zwietering