Exactly like in 99f9609, which fixed the same issue in CallExpression,
the spec tells us to *first* evaluate the arguments, if any, and *then*
check if the provided value is a constructor function.
This change lays the foundation for making the require_promise return
an error hand handling the process abort outside of the syscall
implementations, to avoid cases where we would leak resources.
It also has the advantage that it makes removes a gs pointer read
to look up the current thread, then process for every syscall. We
can instead go through the Process this pointer in most cases.
Although those are the only valid options parse_primary_expression is
sometimes called when only an expression is valid which means it did not
check match_expression and might fail the now removed VERIFY.
Previously we might swallow invalid unicode point which would skip valid
ascii characters. This could be dangerous as we might skip a '"' thus
not closing a string where we should.
This might have been exploitable as it would not have been clear what
code gets executed when looking at a script.
Another approach to this would be simply replacing all invalid
characters with the replacement character (this is what v8 does). But
our lexer and parser are currently not set up for such a change.
This fixes a bug, where we mistakenly put a character in the next row if
the cursor was told to move to the rightmost column when it was already
there.
The this value is only supposed to be set via the BindThisValue and
accessed via the GetThisBinding AOs, so exposing a direct getter/setter
would only lead to potentially non-spec-compliant behavior down the
line.
This patch returns an empty Optional<...> instead of an Error for
Core::System::getgrname and Core::System::getpwnam if we can't find a
matching group or user entry.
It also updates the 'chown' utility to support this new behavior.
Addresses an issue in which a window resize event after history
overflow would cause the Terminal to crash due to a failed assertion.
The problematic assertion was removed and the logic updated to
support inserting lines even when the start of the history is at an
offset (due to an overflow).
Resolves#10987
Implement a mechanism that allows us to alter colors so that they
mimic those a colorblind person would see. From the color we can then
alter the colors for the whole preview so we can simulate everything
in the theme including icons/decorations.
This filter is also available as a Filter in LibGfx so it can be
reused in multiple other places.
The color simulation algorithm is based on this one
https://github.com/MaPePeR/jsColorblindSimulator publicly available.
...for now - the reason being that the AST breaks 'completion bubbling'
and returns a plain Value, and code at the call site relies on the VM
having an exception set when converting the plain value back into a
completion.
Fixes#11301.
Much like the existing in6addr_any global and the IN6ADDR_ANY_INIT
macro, our LibC is also expected to export the in6addr_loopback global
and the IN6ADDR_LOOPBACK_INIT constant.
These were found by the stress-ng port.
These POSIX APIs are defined as mapping directly to
`strrchr` and `strchr` respectively.
These are needed for the latest version of the stress-ng port,
and also give us better POSIX compliance.
This means we can get rid of the hacks where we were peeking a code
point instead of getting the next one so that we could peek_twin()
later. Now, we follow the spec more closely. :^)
This fixes the crash that Luke found using Domato:
```css
. foo {
mso-border-alt: solid .-1pt;
}
```
The spec distinguishes between "If the next 3 code points would
start..." and "If the input stream starts with..." but we were treating
them the same way, skipping the first code point in the process.
These correspond to "If the input stream starts with..." in the spec,
which up until now we were not handling correctly, which led to some fun
bugs.
As noted, reconsuming the input code point in order to read its value is
hacky, but works. Keeping track of the current code point in Tokenizer
would be nicer, when I'm feeling brave enough to mess with it!
These are all pretty simple so I thought I would add them all in one go:
- socket()
- bind()
- listen()
- accept()
- accept4()
- connect()
- shutdown()
- send()
- sendmsg()
- sendto()
- recv()
- recvmsg()
- recvfrom()
- getsockopt()
- setsockopt()
- getsockname()
- getpeername()
- socketpair()
This implements:
- console.group()
- console.groupCollapsed()
- console.groupEnd()
In the Browser, we use `<details>` for the groups, which is not actually
implemented yet, so groups are always open.
In the REPL, groups are non-interactive, but still indent any output.
This looks weird since the console prompt and return values remain on
the far left, but this matches what Node does so it's probably fine. :^)
I expect `console.group()` is not used much outside of browsers.
The spec very kindly defines `Printer` as accepting
"Implementation-specific representations of printable things such as a
stack trace or group." for the `args`. We make use of that here by
passing the `Trace` itself to `Printer`, instead of having to produce a
representation of the stack trace in advance and then pass that to
`Printer`. That both avoids the hassle of tracking whether the data has
been html-encoded or not, and means clients don't have to implement the
whole `trace()` algorithm, but only the code needed to output the trace.
The `CountReset` log level is displayed as a warning, since the message
is always to warn that the counter doesn't exist. This is also in line
with the table at https://console.spec.whatwg.org/#loglevel-severity
This implements the Logger and Printer abstract operations defined in
the console spec, and stubs out the Formatter AO. These are then used
for the "output a categorized log message" functions.
