This matches the likes of the adopt_{own, ref}_if_nonnull family and
also frees up the name to allow us to eventually add OOM-fallible
versions of these functions.
Now that expression evaluation can use TRY, we can allow binary operator
methods to fail as well. This also fixes a few instances of converting a
Value to a double when we meant to convert to an integer.
If a tuple has a single value, perform a comparison using that singular
value. This allows, for example, comparisons of the form "(1) < 4",
where (1) is a single element tuple.
There's a fair amount of VERIFY/TODO calls in LibSQL that will crash the
SQL server if we hit an unimplemented feature or some bug. Restart the
server if this happens to help with debugging / development.
Move the definitions for maximum argument and environment size to
Process.h from execve.cpp. This allows sysconf(_SC_ARG_MAX) to return
the actual argument maximum of 128 KiB to userspace.
Error codes can leak information about veiled paths, if the path
resolution fails with e.g. EACCESS.
This is non-trivial to fix, as there is a group of error codes we want
to propagate to the caller, such as ENOMEM.
VirtualFileSystem::mkdir() relies on resolve_path() returning an error,
since it is only interested in the out_parent passed as a pointer. Since
resolve_path_without_veil returns an error, no process veil validation
is done by resolve_path() in that case. Due to this problem, mkdir()
should use resolve_path_without_veil() and then manually validate if the
parent directory of the to-be-created directory is unveiled with 'c'
permissions.
This fixes a bug where the mkdir syscall would not respect the process
veil at all.
Previously, VirtualFileSystem::resolve_path() could return a non-null
RefPtr<Custody>* out_parent even if the function errored because the
path has been veiled.
If code relies on recieving the parent custody even if the path is
veiled, it should just call resolve_path_without_veil and do the veil
validation manually. This is because it could be that the parent is
unveiled but the child isn't or the other way round.
I noticed after upgrading my machine that the QEMU is no longer building
due to GCC enabling `-fcf-protection` by default, even for targets that
don't support it.
The included patch came from the QEMU development list, but hasn't be
included in any patch releases at the time of writing.
https://lore.kernel.org/all/20220208211937.79580-1-vineetg@rivosinc.com/
Until QEMU patches, lets fix it on our end by patching before we build.
This also switches to checking out a specific commit instead of just the
master HEAD, as the port linter requires a hash (which is imo pointless
in this case), and we can't provide a stable hash for the master branch
HEAD.
This reverts commit 3a184f7841.
This broke a number of test262 tests under "TypedArrayConstructors".
The issue is that the CanonicalNumericIndexString AO should not fail
for inputs like "1.1", despite them not being integral indices.
The difference should be between m_utf8_iterator and the
the new position, if m_prev_utf8_iterator is used one fewer
source position is popped than required.
This issue was not apparent on most pages since restore_to
used for tokens such <!doctype> that are normally
followed by a newline that resets the column to zero,
but it can be seen on pages with minified HTML.
Putting everything in the global scope will lead to mayhem and failing
tests with an actually correct implementation of scoping :^)
Also adds in a tiny debug log of the exception, otherwise we'd be
staring at failing tests with no info on what failed.
Now we emit CreateVariable and SetVariable with the appropriate
initialization/environment modes, much closer to the spec.
This makes a whole lot of things like let/const variables, function
and variable hoisting and some other things work :^)
Instead of crashing on the spot, return a descriptive error that will
eventually continue its days as a javascript "InternalError" exception.
This should make random crashes with BC less likely.
This patch makes check_identifier_name_for_assignment_validity()
take a FlyString instead of a StringView. We then exploit this by
passing FlyString in more places via flystring_value().
This gives a ~1% speedup when parsing the largest Discord JS file.
When parsing identifiers, we ultimately want to sink the token string
into a FlyString anyway, and since Token may have a FlyString already
inside it, this allows us to bypass the costly FlyString(StringView).
This gives a ~3% speedup when parsing the largest Discord JS file.
Everyone who calls this already has a FlyString, so we were doing *way*
more work by pessimizing it to a StringView.
This gives a ~2% speedup when parsing the largest Discord JS file.
If the current character under the lexer cursor is ASCII, we don't need
to create a Utf8View to consume a full code point.
This gives a ~3% speedup when parsing the largest Discord JS file.
