identifier_str might look a bit overengineered, but we want to reuse
this bit of code and it needs a reference to the token from which to
pick the identifier.
The problem with this is that the token would be owned by self, but
the function needs to mutate (the interner), so this implementation is
the most straightforward way of acquiring and working with an
immutable reference to the token before interning the identifier.
Change-Id: I618ce8f789cb59b3a9c5b79a13111ea6d00b2424
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2592
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Making this function a macro instead makes it possible to match
arbitrary token kinds, even the ones that carry data, without changing
the syntax too much.
Change-Id: I5cda9e36d6833bd9c259f7d4d8340db6e783b4e8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2593
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
These aren't particularly useful without side effects, but one step at
a time.
This diverges slightly from the book, in that OpPop retains the last
value it "forgot" from the stack in a special field on the
interpreter.
This makes it possible to return values from expression statements,
which helps in cases where Lox is embedded as a scripting
language (please don't do this ever) or in tests.
Change-Id: Ided0bc04c6e80ddb23ba4693d61ac9e08b002d58
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2584
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This is again a step closer to the book, but there are some notable
differences:
* Only constants encountered by the compiler are interned, all other
string operations (well, concatenation) happen with heap objects.
* OpReturn will always ensure that a returned string value is newly
heap allocated and does not reference the interner.
Change-Id: If4f04309446e01b8ff2db51094e9710d465dbc50
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2582
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
... including concatenation.
This diverges significantly from the book, as I'm using std::String
instead of implementing the book's whole heap object management
system.
It's possible that Lox in Rust actually doesn't need a GC and the
ownership model works just fine.
Change-Id: I374a0461d627cfafc26b2b54bfefac8b7c574d00
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2577
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Adds support for true, false & nil. These each come with a new
separate opcode and are pushed directly on the stack.
Change-Id: I405b5b09496dcf99d514d3411c083e0834377167
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2571
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Introduces a new enum which represents the different types of possible
values, and modifies the rest of the existing code to wrap/unwrap
these enum variants correctly.
Notably in the vm module, a new macro has been introduced that makes
it possible to encode a type expectation and return a runtime error in
case of a type mismatch.
Change-Id: I325b5e31e395c62d8819ab2af6d398e1277333c0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2570
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Without this fix we would keep parsing in the same precedence level
and get weird things like:
10 - -10 + 10
=> 10
Change-Id: If2bed4569fbf566027011037165a9b3c09b7427c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2567
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Defines a new precedence levels enum which can be used to restrict the
parser precedence in any given location. As an example, unary
expressions and grouping are implemented, as these have a different
precedence from e.g. expression()
Change-Id: I91f299fc77530f76c3aba717f638985428104ee5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2558
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This lets us suppress reporting of additional errors from the compiler
until a synchronisation point is reached.
Change-Id: Iacf90949f868fbdb4349750065b5e458cf74d32a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2557
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This one necessarily has to diverge more from the book than the
treewalk interpreter did, so some of this is expected to change, but
I'm happy with the rough shape.
Since we're reusing the old scanner, the compiler/parser struct owns
an iterator over all tokens with which the pull-scanner from the
bytecode chapters is simulated.
Change-Id: Icfa0bd4729d9df786e08f7e49a25cba1b9989a91
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2556
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
