Letting the constant resolver throw exceptions prevented us from doing
checking on later initializers anyway, so instead we'll send them to the
error handler. As a special bonus this makes it so we don't crash when
a global variable initializer has errors. Fixes#1850, #1855.
By continuing to generate bytecode even after an error is found, we're
able to find more syntax errors and will also be able to keep the value
stack at the expected height.
By using an extern error handler in the script engine, we can mock that
handler and make sure something that should fail actually does, instead
of having to parse log messages.
RunExpr will evaluate and return the value of a single expression.
RunCode will evaluate a full function body.
RunScript will compile a complete standalone script and return the
return value of its Main() function.
So it turns out that the fix stops the engine from crashing, but it
still doesn't seem to generate valid code - Aul emits an internal error
at runtime.
This commit contains a fairly substantial rewrite of the C4Script code
generator. Instead of generating bytecode while parsing the script,
we're now parsing the script into a syntax tree, and have any further
processing happen on that instead of the raw source.
At this time, the code generator emits the same bytecode as the old
parser; there are several optimization opportunities that arise from the
new possibility to emit code out of order from its specification by the
author.
Compared to the old compiler, this one is still rather deficient when
dealing with incorrect code; it's also not emitting several warnings
that used to be diagnosed.
It isn't clear whether that call is necessary since the C4AulScriptEngine
constructor already does this, but it is clear that duplicating the call
all over is a bad idea.
In the long term, there is no reason DirectExec should be concerned with
C4AulScript/C4ScriptHost. In the meantime, the lookup code from Fneval can
be moved into the function.
This allows eval in scenario script to access scenario script locals, but
that seems harmless.
The C4AulScript containing the source of the function was already mostly
used to get the relevant proplist or available from context. This will
allow more than one proplist plus the global one per scripthost to contain
functions.
Min/Max with array parameter will return the smallest/largest value of
all elements of the array. If any array element is not an integer, nor
convertible to integer, the function will fail.
I'm not a huge fan of testing for warnings by hijacking the logging
routines, but right now there's no way to exfiltrate warnings from Aul
any other way, so it'll have to do.
Overriding the logging functions from C4SimpleLog.cpp has the nice
additional advantage that expected runtime errors no longer get written
to stdout - this is okay because we're already checking that an
exception is thrown.
GTest does not ship precompiled binaries anymore. They are now compiled
using the CMakelists.txt from gtest.
Add basic unit tests for C4Value, DirectExec and C4StringTable.
Nicolas Hake