This is primarily a correctness change, *not* a performance one.
The expected performance impact is minimal anyway.
The goal is to eliminate the use of platform-inconsistent floating-point operations
for this load-bearing task.
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.
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.
The function only stopped at the end of the *arrays*,
not of *their used portions*!
This could cause false negatives one way or the other.
This appears not to affect the palette packing, since the packing algorithm
deals with them efficiently; but it should speed up processing slightly,
and as the test changes show, it also improves the UX of palette packing
error messages!
* Clarify the operator relationship of ordinary and fixed-point numbers
* Attempt to clarify description of fixed-point numbers
* Note that RGBASM does not check fixed-point precisions
* Simplify sine table example a bit
* Remove misleading equations describing `DIV`, `MUL`, and `FMOD`
* Various minor style and formatting fixups
The generated `result.pal` can change between platforms, it turns out
(due to "unstable sort" differences), and creates additional churn if
changing anything related to palette generation.
tl;dr this makes the test less flaky in the long run.
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 :)
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.
* Avoid redirecting error messages in RGBLINK tests
We check that RGBLINK prints nothing to stdout, so all that
would be captured on stdout is a putative failure message.
* Require each RGBLINK test to check error output
Otherwise, you can have a test that just... checks nothing!
* Document how to add tests
Fixes#1300's last remaining item.
Also add `checkdiff` rules to remind us to update that doc if
any of the test driver scripts are updated.
* Allow for optional sections in linker scripts
These are more useful for frameworks/toolchains.
* Check for an active mem region everywhere
Do you like segfaults? Too bad!
* Allow the address to be floating in linker scripts
Try and make the life of SDCC interop easier.
* Also validate alignment when floating
* Overhaul the linker script manual page
Documenting the new features, but also restructuring the
existing documentation to make the manual page (hopefully)
easier to understand.
Notable side effects:
* Use the standard-conformant MSVC preproc
* Add test for linker script INCLUDE
* Improve wording of placement conflict errors
* Fix errors from not newline-terminated files
* Teach checkdiff about the linker script doc
* Call linker script "commands" "directives" instead
---------
Co-authored-by: Rangi42 <[email protected]>
As reported by the following command:
mandoc -T lint man/* | grep -v "input text line longer than 80 bytes"
(One of them also showed up as a warning while setting up Debian packaging.)
Eldred HabertandRangi42
