diff options
| author | Miquel Sabaté Solà <mssola@mssola.com> | 2026-04-23 22:17:23 +0200 |
|---|---|---|
| committer | Miquel Sabaté Solà <mssola@mssola.com> | 2026-04-23 22:17:23 +0200 |
| commit | 7c01c29cec6f5fcc94abcd154c47d2c78f765a78 (patch) | |
| tree | d2ecd86e92047e071cfbbe97845ab3353915ec9f /.github/workflows/ci.yml | |
| parent | b0def33f13f1fc2403b1a0bc6666ec874314d4ad (diff) | |
| download | tools.nes-7c01c29cec6f5fcc94abcd154c47d2c78f765a78.tar.gz tools.nes-7c01c29cec6f5fcc94abcd154c47d2c78f765a78.zip | |
Ensure expressions in arguments are fully parsed
Imagine the following scenario:
lda #.lobyte(@address + 1)
Here we have an immediate which comes from the .lobyte call. That being
said, since this is using the '#' symbol, we look ahead after noticing
it just in case we need to disambiguate some scenarios. When a
parenthesis is found, in extract_paren_expression() we temporarily
discard the looking ahead status as expressions inside of parenthesis
are no longer affected by any hypothetical external ambiguity. This,
though, was not being done in parse_arguments(), which is the function
that would be called in the above scenario.
Hence, ensure that we temporarily decrease the look ahead status for the
inner arguments, and then increase it back when we are done. This way,
when the parser finds '@address', it will no longer go the "we have
found a 'value', refrain from ambiguities and return early" route, and
it will check for any binary expression.
Note that all this dance actually applied here, as binary operations are
a source of ambiguities, and the look ahead mechanism was brought about
because of these kinds of expressions. Hence, it's not like the look
ahead mechanism is troublesome in on itself, we just missed the special
handling on this specific scenario.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
Diffstat (limited to '.github/workflows/ci.yml')
0 files changed, 0 insertions, 0 deletions
