After 8cd59bf7c4 any file included by qjs
with -I that would parse as a module is eval'd as so, which is usually
not the intent, but rather to define some global functions.
Rather than having the user take care of JSMallocState, take care of the
bookkeeping internally (and make JSMallocState non-public since it's no
longer necessary) and keep the allocation functions to the bare minimum.
This has the advantage that using a different allocator is just a few
lines of code, and there is no need to copy the default implementation
just to moficy the call to the allocation function.
Fixes: https://github.com/quickjs-ng/quickjs/issues/285
Since we don't keep timers sorted by deadline but by insertion order,
the test is flaky in slow environments (GHA seemingly). Increase the
timeouts to give it a bigger chance of success.
ASan / UBSan builds are notoriously slow, so skip the test in those.
I find it convenient to have access to JS_ReadObject and JS_WriteObject
from JS land. That's precisely the functionality that tests/bjson.c
provides, ergo, move it into quickjs-libc.c
- DUMP_XXX defined as nothing or 0 produces unconditional output
- DUMP_XXX defined as a bitmask produces conditional output based
on command line option -d<bitmask>
- add `JS_SetDumpFlags()` to select active dump options
- accept -d[<hex mask>] and --dump[=<hex mask>] to specify active
dump options, generalize command line option handling
- improve DUMP_READ_OBJECT output, fix indentation issue
The shell script runs the tests and diffs stdout against v8.txt.
Lines added/removed means tests were broken/fixed.
Future work is to a) fix failing tests, and b) enable more tests.
A number are disabled for various reasons and mjsunit subdirectories are
currently skipped. Need to decide on a case-by-case basis what is and
isn't relevant to us.
At the moment about 430 tests are run of which approx. 80% pass.
run-test262 required pthreads, so let's add that. In addition, in MinGW,
clock_gettime is implemented in the pthreads library, so we want to link
it too.
This doesn't get us anywhere closer to building with ClangCL on Windows,
but hey, another target that required some tweaking...
