This currently only supports pair iterables (i.e. iterable<key, value>)
support for value iterables (i.e. iterable<value>) is left as TODO().
Since currently our cmake setup calls the WrapperGenerator separately
and unconditionally for each (hard-coded) output file iterable wrappers
have to be explicitly marked so in the CMakeLists.txt declaration, we
could likely improve this in the future by querying WrapperGenerator
for the outputs based on the IDL.
This patch essentially just splits the non return-specific logic from
generate_return_statement (i.e. the wrapping of the cpp value into
a javascript one) into a separate function generate_wrap_statement that
can be used to wrap any cpp value during wrapper generation.
SonarCloud flagged the read of the matches array as a potential garbage
read. I don't believe the case it flagged was possible to reach due to
how the code is structured, however we should really just be zero
initializing these stack arrays.
SonarCloud flagged this 'Identical sub-expressions on both sides of
operator "||"'. When looking at the git history it looks like it was
just a copy / paste mistake that happened when Token::Type::Arrow
support was added.
SonarCloud flagged this as m_delay_buffer is technically uninitialized
at the point at which the POD types are initialized in a constructor.
I don't check to see if this was actually a real issue, as the member
is ultimately unused. So lets just get rid of it.
While trying to investigate a problem with the ssl module in the python
port I found that the SystemMonitor Stack tab for a process wouldn't
show the symbols for the libssl and libcrypto shared libraries that are
installed under /usr/local/lib. The main reason for this is that
LibSymbolication didn't look for libraries under /usr/local/lib.
This commit adds support for looking for libraries under /usr/local/lib.
Absolute paths are still respected, and lookup gives precedence to
/usr/lib, just like dynamic linker does.
We already know the length of these substrings, so there's no need to
check their lengths using strlen in the StringView(char*) constructor.
This patch also removes an accidental 1-byte OOB read that was left over
from when this method received null-terminated char pointers instead of
string views, as well removes the unnecessary lambda call (two of the
checks were impossible, and this was only called in one place, so we can
just inline it)
This is used surprisingly often. For example, it is used by a core
YouTube library called Structured Page Fragments.
It allows you to manually dispatch an event with arbitrary data
attached to it.
The only thing missing from this implementation is the constructor.
This is because WrapperGenerator is currently missing dictionary
capabilities.
I noticed some events we being wrapped into a generic Event while
working on CustomEvent. This also adds PageTransitionEvent's
constructor to the WindowObject.
I'm not sure if this is all of them.
This custom attribute will be used for objects that hold onto arbitrary
JS::Value's. This is needed as JS::Handle can only be constructed for
objects that implement JS::Cell, which JS::Value doesn't.
This works by overriding the `visit_edges` function in the wrapper.
This overridden function calls the base `visit_edges` and then forwards
it to the underlying implementation.
This will be used for CustomEvent, which must hold onto an arbitrary
JS::Value for it's entire lifespan.
If the first element of an SVG path spec uses relative coordinates,
we'll now treat them as absolute. This is achieved by defaulting to
(0,0) as the initial "last point" in the path.
Prior this change, if you had a program which frequently reads small
amount of bytes, then it would constantly fire up syscalls.
This patch sets that the minimum size that is passed to the read syscall
is 1024 and then it saves these additional bytes in a buffer for next
reads, which greatly improves the cpu usage on such cases.
In other words: reading flacs is now very efficient.
Instead of blindly forcing BGR format on the bochs-display device, let's
ensure we do that only on QEMU bochs-display and not on VirtualBox
graphics adapter too.
In some cases these can be several KiB or more in size, making checking
very slow, and it doesn't make sense to filter them out anyway. This
change speeds up loading pages with large data: urls, which previously
took up to 1ms per byte to process.
- .text now starts at 0x80000, where an actual (non-qemu) RPi expects
- use magic section name ".text.first" to make sure the linker script
puts the kernel entry point at the start of the .text section
- remove a few things from the x86 linker script that aren't needed
for aarch64 (yet?)
This moves Kernel/Prekernel/linker.ld unchanged to
Kernel/Prekernel/Arch/aarch64 and Kernel/Prekernel/Arch/x86.
The aarch64 will change in a future commit.
No behavior change.
If a page is nice enough to give us some preload hints, we can tell
RequestServer to get started on downloading the resources right away,
instead of waiting until discovering them later on during parsing.
The ECMAScript spec says that Date parsing can support any number of
implementation-defined date formats. So let's support a format commonly
used on the web. And let Core::DateTime do the heavy lifting. :^)
