tools.nes/tests/expected/unused_definition.txt, branch mainTools for NES/Famicom development.
https://git.mssola.com/nes/tools.nes/atom?h=main2026-07-07T21:26:50ZBe more specific on unused objects2026-07-07T21:26:50ZMiquel Sabaté Solàmssola@mssola.com2026-07-07T21:25:49Zurn:sha1:2b1356d371b52d68243ddebbfcf3f65047c2fd76
It was downright lazy from my end to not inspect the line of the object
that was being unused. Fix this by trying to fetch the bundle's node.
This right now applies to variable definitions. Objects like macro
arguments are pending to be done.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
Refer to the original file for unused objects2026-06-05T21:32:39ZMiquel Sabaté Solàmssola@mssola.com2026-06-05T21:32:39Zurn:sha1:85a68dbdcd0200a711bacda9c7170129350813c8
When warning users on unused objects (e.g. variables, proc's), we have
to pick up the source of origin for this warning. In places where the
original PNode is not available, then we go with the last source we have
at hand, as that's the usual way to go (i.e. the error occurred at the
current source/context).
That being said, for unused objects that's not desirable, because we
might otherwise claim the error to happen on the file we first
targetted, but it's way more useful to understand where the object was
defined.
Hence, when defining a variable, address or proc, let's actually store
the PNode associated with it as well. This way the checker can hopefully
get the source from this PNode and be more clear to the user.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>